بروتوكول الإنترنت (الإصدار السادس): الفرق بين النسختين
[نسخة منشورة] | [نسخة منشورة] |
وسم المقالة |
ط بوت: إصلاح أخطاء فحص ويكيبيديا من 1 إلى 104 |
||
(294 مراجعة متوسطة بواسطة 16 مستخدماً غير معروضة) | |||
سطر 1: | سطر 1: | ||
{{ |
{{عن|بروتوكول الإنترنت (الإصدار السادس)||بروتوكول الإنترنت (توضيح)}} |
||
{{صندوق معلومات بروتوكول شبكة |
{{صندوق معلومات بروتوكول شبكة |
||
| title = الإصدار السادس من بروتوكول الإنترنت |
| title = الإصدار السادس من بروتوكول الإنترنت |
||
| name = {{إنج|Internet Protocol version 6}} |
|||
| image = IPv6 header-ar.svg |
| image = IPv6 header-ar.svg |
||
| caption = [[ترويسة]] الإصدار السادس من بروتوكول الإنترنت |
| caption = [[ترويسة (حوسبة)|ترويسة]] الإصدار السادس من بروتوكول الإنترنت |
||
| abbrrviation = IPv6 |
| abbrrviation = IPv6 |
||
| purpose = بروتوكول تشبيك |
| purpose = بروتوكول تشبيك |
||
سطر 11: | سطر 10: | ||
| influenced = الإصدار الرابع من بروتوكول الإنترنت |
| influenced = الإصدار الرابع من بروتوكول الإنترنت |
||
| osilayer = [[طبقة الشبكة]] |
| osilayer = [[طبقة الشبكة]] |
||
| rfcs = |
| rfcs = |
||
}} |
}} |
||
'''الإصدار السادس من بروتوكول الإنترنت''' {{إنج|Internet Protocol Version 6 |
'''الإصدار السادس من بروتوكول الإنترنت''' {{إنج|Internet Protocol Version 6 اختصارًا IPv6}} هو [[بروتوكول (اتصالات)|بروتوكول]] [[تشبيك]] يعمل في [[طبقة الشبكة]] حسبَ [[نموذج الربط البيني للأنظمة المفتوحة]]، يُستعمل هذا البروتوكول في شبكات البيانات ويقدم خدمات العنونة والتقطيع وإدارة حركة البيانات.<ref name="REF-AR1" group="ar">{{استشهاد مختصر|1=بكني|2=2022|ص=204}}</ref> طوِّر الإصدار السادس في عام 1995م على يد [[مجموعة مهندسي الإنترنت]] بصفته حلًّا نهائيًّا [[استنفاد فضاء عناوين الإصدار الرابع من بروتوكول الإنترنت|لمشكلة استنفاد فضاء عناوين الإصدار الرابع من بروتوكول الإنترنت]].<ref name="RFC-11"/> |
||
يُعرِّف البروتوكول [[ترويسة (حوسبة)|ترويسة]] ثابتة الطول: 40 [[بايت |
يُعرِّف البروتوكول [[ترويسة (حوسبة)|ترويسة]] ثابتة الطول: 40 [[بايت]]ًا، تضاف إلى جميع [[رزمة بيانات|رزم البيانات]] التي يُنشئها، وتوجد أيضًا مجموعة من ترويسات التوسعة التي يمكن استخدامها بشكل اختياري حسب الحاجة عند أداء وظائف معينة مثل [[تقطيع (شبكات)|التقطيع]] و[[توجيه (شبكات)|التوجيه]]. يمكن أن تحتوي رزمة بيانات الإصدار السادس على أكثر من ترويسة توسعة تلي ترويسة البروتوكول.<ref name="RFC-138">{{استشهاد مختصر|RFC 8200|ص=7-10|لغة=en}}</ref> |
||
يُعرِّف البروتوكول فضاءً من العناوين يضم قرابة 3.4x10<sup>38</sup> |
يُعرِّف البروتوكول فضاءً من العناوين يضم قرابة 3.4x10<sup>38</sup> عنوانًا طول كل منها 128 بتًّا.<ref name="Book-11"/> يُقسَّم الفضاء رياضيًّا إلى فضاء [[بث فريد|البث فريد الوجهة]] وإلى فضاء [[بث متعدد الوجهات|البث المجموعاتي]]، وتدير [[أيانا|هيئة العناوين المُخصصة]] كلا الفضاءَين. يدعم البروتوكول ثلاثة أنماط من العنونة هي العنونة فريدة الوجهة وعنونة [[بث نحو الأقرب|البث نحو الأقرب]] وعنونة البث المجموعاتي، ولا يدعم [[بث عام (شبكات)|البث العام]].<ref name="RFC-26"/> |
||
تصف مُحددات البروتوكول آليةً لتقطيع رزم البيانات في مصادرها فقط، وذلك لأن البروتوكول يدعم |
تصف مُحددات البروتوكول آليةً لتقطيع رزم البيانات في مصادرها فقط، وذلك لأن البروتوكول يدعم أيضًا آليةً لاكتشاف حجم وحدة النقل العظمى لمسار رزمة بيانات ما قبل إرسالها، فيختار طول رزمة متوافقًا معه، ولا حاجة لإجراء التقطيع في عقد الشبكة الموجودة على المسار كما هو الحال في [[بروتوكول الإنترنت (الإصدار الرابع)|الإصدار الرابع من البروتوكول]]. في الوجهة النهائية، تحصل عملية إعادة التجميع، وفيها يعاد تشكيل الرزمة الأصلية انطلاقًا من القطع المُستقبلة.<ref name="RFC-113"/> |
||
يدعم الإصدار السادس |
يدعم الإصدار السادس أيضًا آليتين لإدارة حركة البيانات في الشبكة. الآلية الأولى هي تعريف تدفقات لرزم البيانات، وهي طريقة لتحديد مجموعة من الرزم المرسلة من مصدر محدد إلى وجهة محددة، ويُستعمل لأجل ذلك حقل مخصص في ترويسة البروتوكول.<ref name="RFC-29"/> أما الآلية الثانية فهي دعم مستويات متعددة [[جودة الخدمة|لجودة الخدمة]] في الشبكة، ثم تحديد المستوى المطلوب لكل رزمة باستعمال حقل مُخصص لذلك في ترويسة البروتوكول. في كلتا الآليتين، لا يحدد البروتوكول كيفية معالجة الرزم بشكل تفضيلي، ولكنه يشرح كيفية تمييزها في المرحلة التي تسبق معالجتها.<ref name="RFC-30"/> |
||
ينشأ عن استعمال الإصدار السادس من بروتوكول الإنترنت مجموعة من الثغرات الأمنية التي قد تكون |
ينشأ عن استعمال الإصدار السادس من بروتوكول الإنترنت مجموعة من الثغرات الأمنية التي قد تكون منطلقًا لمجموعة من الهجمات، بعضها مرتبط بالتقطيع مثل هجوم القطعة الصغيرة أو هجوم القطع المتراكبة،<ref name = "REF-20" group="ar"/> وبعضها مرتبط بإدارة حركة رزم البيانات مثل هجوم سرقة الخدمة.<ref name="RFC-127"/> |
||
== نبذة تاريخية == |
== نبذة تاريخية == |
||
سطر 30: | سطر 29: | ||
[[ملف:IPv6 timeline-ar.svg|تصغير|يسار|300بك|خط زمني للمعايير الناظمة للإصدار السادس من بروتوكول الإنترنت والبروتوكولات الرديفة له.]] |
[[ملف:IPv6 timeline-ar.svg|تصغير|يسار|300بك|خط زمني للمعايير الناظمة للإصدار السادس من بروتوكول الإنترنت والبروتوكولات الرديفة له.]] |
||
بدءًا من سبعينيات [[القرن 20|القرن العشرين]]، ابتدأ نمو وانتشار شبكة بيانات حول العالم، كانت نقطة الانطلاق من المراكز البحثية والجامعات في [[الولايات المتحدة|الولايات المتحدة الأمريكية]]، وسُميت هذه الشبكة [[أربانت|بالأربانت]] في بداياتها. اعتمدت هذه الشبكة على مجموعة من [[بروتوكول (اتصالات)|البروتوكولات]] التي طورتها [[داربا|وكالة مشاريع البحوث المتطورة الدفاعية]]، ومنها [[بروتوكول الإنترنت (الإصدار الرابع)|الإصدار الرابع من بروتوكول الإنترنت]] الذي استخدم لعنونة التجهيزات المُتصلة مع الشبكة بصورة فريدة عالميًّا.<ref name="RFC-1">{{استشهاد مختصر|RFC 791|ص=1|لغة=en}}</ref> في مطلع التسعينيات، بدأ استخدام الإنترنت تجاريًّا، وأصبح من الشائع تقديم الخدمات أو بيع المُنتجات عبر الإنترنت، وسبب هذا نموًا سريعًا للشبكة خاصة في [[الولايات المتحدة|الولايات المُتحدة الأمريكية]].<ref name="Book-1">{{استشهاد مختصر|Odom|2013|ص=611|لغة=en}}</ref> |
|||
اعتمد الإصدار الرابع من بروتوكول الإنترنت على نظام عنونة مبني على فضاء يبلغ طول العنوان فيه 32 |
اعتمد الإصدار الرابع من بروتوكول الإنترنت على نظام عنونة مبني على فضاء يبلغ طول العنوان فيه 32 بتًّا، وُقسِّم هذا الفضاء إلى أصناف، خُصصت ثلاثٌ منها لعنونة [[بث فريد|البث فريد الوجهة]]، وهي الصنف A وعدد أفضيته 128 صنفًا، وهو أكبر الأصناف حجمًا (2<sup>24</sup> عنوانًا في كل صنف)، والصنف B وضمَّ الفضاء 2<sup>14</sup> صنفًا في كل منها 2<sup>16</sup> عنوانًا، والصنف C وهو أكثر الأصناف عددًا بواقع 2<sup>21</sup> صنفًا، ولكنها أصغرها حجمًا، حيث يضمّ كل صنف 2<sup>8</sup> عنوانًا.<ref name="RFC-2">{{استشهاد مختصر|RFC 791|ص=7|لغة=en}}</ref><ref name="Book-2">{{استشهاد مختصر|Odom|2013|ص=296|لغة=en}}</ref> وخُصص فضاء رابع [[بث متعدد الوجهات|للبث المجموعاتي]]، وسمي الصنف D.<ref name="RFC-3">{{استشهاد مختصر|RFC 1112|ص=3|لغة=en}}</ref> |
||
|الأخير= Deering |
|||
|الأول= S. |
|||
| تاريخ= أغسطس 1989 |
|||
| مسار أرشيف = https://web.archive.org/web/20200203093018/https://tools.ietf.org/html/rfc1112 |
|||
| مسار= https://tools.ietf.org/html/rfc1112 |
|||
| عنوان= RFC 1112, Host Extensions for IP Multicasting |
|||
| موقع=The Internet Society |
|||
| صفحة = 3 |
|||
| لغة= en |
|||
|doi= 10.17487/RFC1112 |
|||
| تاريخ الوصول= 5 سبتمبر 2019 |
|||
|تاريخ أرشيف=2020-02-03}}</ref> |
|||
شكَّلت [[مجموعة مهندسي الإنترنت]]، وهي الهيئة الناظمة لتطوير معايير الإنترنت، في شهر نوفمبر من العام 1991م، مجموعة عمل التوجيه والعنونة والمعروفة اختصارًا باسم رُوْد {{إنج|Routing and Addressing اختصاراً ROAD}} بهدف معالجة هذه المشكلة، وعرَّفت هذه المجموعة ثلاثَ مُشكلات رئيسيَّة تعيق نمو الإنترنت:<ref name="RFC-4">{{استشهاد مختصر|RFC 4632|ص=4|لغة=en}}</ref> |
|||
# استنفاد فضاء عناوين الصنف B، وهذه هي نتيجة لغياب فضاء عناوين يناسب منظمة متوسطة الحجم، ففضاء الصنف C صغير الحجم، وهو ما يدفع هذه المنظمات لاستعمال فضاء من الصنف B، على الرغم من أن حجم الفضاء يزيد بكثير عن حاجة المنظمة. |
# استنفاد فضاء عناوين الصنف B، وهذه هي نتيجة لغياب فضاء عناوين يناسب منظمة متوسطة الحجم، ففضاء الصنف C صغير الحجم، وهو ما يدفع هذه المنظمات لاستعمال فضاء من الصنف B، على الرغم من أن حجم الفضاء يزيد بكثير عن حاجة المنظمة. |
||
سطر 52: | سطر 39: | ||
# الاستنفاد النهائي لفضاء عناوين الإصدار الرابع. |
# الاستنفاد النهائي لفضاء عناوين الإصدار الرابع. |
||
لقد كانت المشكلتان الأولى والثانية وشيكتا الحصول، وكان يتوقع حصول أيٍّ منهما بدءًا من العام 1993م.<ref name="RFC-5">{{استشهاد مختصر|RFC 1338|ص=1|لغة=en}}</ref> نتيجة لذلك، طوِّرت الحلول ضمن إستراتيجيتين، تشمل الأولى حلولًا سريعة التطبيق قصيرة الأمد، وهي تستهدف المشكلتان الأولى والثانية، أمَّا الثانية، فتُعنى بحلٍ نهائيٍّ دائمٍ طويل الأمد.<ref name="RFC-6">{{استشهاد مختصر|RFC 1519|ص=1|لغة=en}}</ref> طوِّر التوجيه غير الصنفي بين النطاقات في العام 1992م في إطار الإستراتيجية الأولى،<ref name="RFC-4"/> وتلاه تقنية [[ترجمة عنوان الشبكة]] في العام 1994م.<ref name="RFC-7">{{استشهاد مختصر|RFC 1631|ص=1|لغة=en}}</ref> نجحت حلول الإستراتيجية قصيرة الأمد في إطالة عمر الإصدار الرابع من بروتوكول الإنترنت من خلال إبطاء [[استنفاد فضاء عناوين الإصدار الرابع من بروتوكول الإنترنت|استنفاد الفضاء]].<ref name="Book-3">{{استشهاد مختصر|Odom|2013|ص=612|لغة=en}}</ref> ولكن وعلى أي حال، فبعد أكثر من عقد من الزمن، وتحديدًا في شهر يناير من العام 2011م، استُنفد فضاء عناوين الإصدار الرابع من بروتوكول الإنترنت على المستوى العالمي تمامًًا.<ref group="Web">{{استشهاد ويب |
|||
لقد كانت المشكلتان الأولى والثانية وشيكتا الحصول، وكان يتوقع حصول أيٍّ منهما بدءاً من العام 1993م.<ref name="RFC-5">{{استشهاد ويب |
|||
| الأخير= Fuller |
|||
| الأول= V. |
|||
| الأخير2= Li |
|||
| الأول2= T. |
|||
| الأخير3= Yu |
|||
| الأول3= J. |
|||
| الأخير4= Varadhan |
|||
| الأول4= K. |
|||
| تاريخ= سبتمبر 1993 |
|||
| مسار أرشيف = https://web.archive.org/web/20200120173037/https://tools.ietf.org/html/rfc1338 |
|||
| مسار= https://tools.ietf.org/html/rfc1338 |
|||
| عنوان= RFC 1338, Supernetting: an Address Assignment and Aggregation Strategy |
|||
| لغة= en |
|||
| doi = 10.17487/RFC1338 |
|||
|تاريخ أرشيف=2020-01-20}}</ref> نتيجة لذلك، طوِّرت الحلول ضمن إستراتيجيتين، تشمل الأولى حلولاً سريعة التطبيق قصيرة الأمد، وهي تستهدف المشكلتان الأولى والثانية، أمَّا الثانية، فتُعنى بحلٍ نهائيٍّ دائمٍ طويل الأمد.<ref name="RFC-6"> |
|||
{{استشهاد ويب |
|||
| الأخير= Fuller |
|||
| الأول= V. |
|||
| الأخير2= Li |
|||
| الأول2= T. |
|||
| الأخير3= Yu |
|||
| الأول3= J. |
|||
| الأخير4= Varadhan |
|||
| الأول4= K. |
|||
| تاريخ= سبتمبر 1993 |
|||
| مسار= https://tools.ietf.org/html/rfc1519 |
|||
| عنوان= RFC 1519, Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy |
|||
| لغة= en |
|||
| doi = 10.17487/RFC1519 |
|||
|مسار أرشيف= https://web.archive.org/web/20200306033649/https://tools.ietf.org/html/rfc1519 |
|||
|تاريخ أرشيف=2020-03-06}}</ref> في إطار الإستراتيجية الأولى، طوِّر التوجيه غير الصنفي بين النطاقات في العام 1992م،<ref name="RFC-4"/> وتلاه تقنية [[ترجمة عنوان الشبكة]] في العام 1994م.<ref name="RFC-7">{{استشهاد ويب |
|||
| الأخير= Egevang |
|||
| الأول= K. |
|||
| الأخير2= Francis |
|||
| الأول2= P. |
|||
| تاريخ= مايو 1994 |
|||
| مسار أرشيف = https://web.archive.org/web/20200125032424/https://tools.ietf.org/html/rfc1631 |
|||
| مسار= https://tools.ietf.org/html/rfc1631 |
|||
| عنوان= RFC 1631, The IP Network Address Translator (NAT) |
|||
| لغة= en |
|||
| doi = 10.17487/RFC1631 |
|||
| تاريخ الوصول = 12 يناير 2020 |
|||
|تاريخ أرشيف=2020-01-25}}</ref> نجحت حلول الإستراتيجية قصيرة الأمد في إطالة عمر الإصدار الرابع من بروتوكول الإنترنت من خلال إبطاء [[استنفاد فضاء عناوين الإصدار الرابع من بروتوكول الإنترنت|استنفاد الفضاء]].<ref name="Book-3">Cisco CCENT/CCNA ICND1, P.612</ref> ولكن وعلى أي حال، فبعد أكثر من عقد من الزمن، وتحديداً في شهر يناير من العام 2011م، استُنفد فضاء عناوين الإصدار الرابع من بروتوكول الإنترنت على المستوى العالمي تماماً.<ref name="Web-1">{{استشهاد ويب |
|||
| مؤلف = |
| مؤلف = |
||
| مسار أرشيف = https://web.archive.org/web/20200305002101/https://www.nro.net/ipv4-free-pool-depleted |
| مسار أرشيف = https://web.archive.org/web/20200305002101/https://www.nro.net/ipv4-free-pool-depleted |
||
سطر 102: | سطر 46: | ||
| مسار= https://www.nro.net/ipv4-free-pool-depleted |
| مسار= https://www.nro.net/ipv4-free-pool-depleted |
||
| عنوان= Free Pool of IPv4 Address Space Depleted |
| عنوان= Free Pool of IPv4 Address Space Depleted |
||
| صفحة = |
|||
| موقع= Number Resource Organization |
| موقع= Number Resource Organization |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 6 مارس 2019}}</ref> |
| تاريخ الوصول= 6 مارس 2019}}</ref> |
||
في ما يخص الإستراتيجية طويلة الأمد، فقد بدأت مجموعة مهندسي الإنترنت في العمل منذ مطلع التسعينيات على تطوير إصدار جديد من بروتوكول الإنترنت. في العام 1993م، كان التوجه العام هو طرح نظام عنونة جديد موسع في إصدار جديد من بروتوكول الإنترنت، ولذلك طلبت المجموعة اقتراحات في هذا الشأن مع نهاية تلك السنة.<ref name="RFC-8">{{استشهاد مختصر|RFC 1550|ص=1|لغة=en}}</ref> في نهاية العام 1993م أيضًا، شكّلت المجموعة نطاق عمل جديد سمته الجيل التالي من بروتوكول الإنترنت {{إنج|IP Next Generation اختصاراً IPng}}،<ref name="RFC-9">{{استشهاد مختصر|RFC 1752|ص=2|لغة=en}}</ref> وعمل 15 مهندسًا من اختصاصات متنوعة على مراجعة ودراسة الاقتراحات لصياغة حل شامل.<ref name="RFC-10">{{استشهاد مختصر|RFC 1752|ص=45|لغة=en}}</ref> |
|||
| الأخير= Bradner |
|||
| الأول= S. |
|||
| الأخير2= Mankin |
|||
| الأول2= A. |
|||
| تاريخ= ديسمبر 1993 |
|||
| مسار أرشيف = https://web.archive.org/web/20191204224600/https://tools.ietf.org/html/rfc1550 |
|||
| مسار= https://tools.ietf.org/html/rfc1550 |
|||
| عنوان= RFC 1550, IP: Next Generation (IPng) White Paper Solicitation |
|||
| لغة= en |
|||
| doi = 10.17487/RFC1550 |
|||
|تاريخ أرشيف=2019-12-04}}</ref> في نهاية العام 1993م أيضاً، شكّلت المجموعة نطاق عمل جديد سمته الجيل التالي من بروتوكول الإنترنت {{إنج|IP Next Generation اختصاراً IPng}}،<ref name="RFC-9">RFC 1752, P.2</ref> وعمل 15 مهندساً من اختصاصات متنوعة على مراجعة ودراسة الاقتراحات لصياغة حل شامل.<ref name="RFC-10">RFC 1752, P.45</ref> |
|||
في شهر ديسمبر من العام 1995، صدر المعيار الأول للإصدار السادس من بروتوكول الإنترنت تحت الاسم الرمزي RFC 1883.<ref name="RFC-11">{{استشهاد مختصر|RFC 1883|ص=1|لغة=en}}</ref> وصدر معه أيضًا المعياران الأولان لمُحددات بنية العناوين في الإصدار السادس ولبروتوكول رسائل التحكم للإصدار السادس، وحملت [[طلب تعليقات|وثائق طلب التعليقات]] الخاصة بهما الاسمين الرمزيين RFC 1884 وRFC 1885 على الترتيب.<ref name="RFC-12">{{استشهاد مختصر|RFC 1884|ص=1|لغة=en}}</ref><ref name="RFC-13">{{استشهاد مختصر|RFC 1885|ص=1|لغة=en}}</ref> صدر المعياران الأولان [[بروتوكول اكتشاف الجيران|لبروتوكول اكتشاف الجيران]] ولآلية التهيئة الذاتية الآلية لاحقًا في شهر أغسطس من العام التالي، وحملا الاسمين الرمزيين على RFC 1970 وRFC 1971 على الترتيب.<ref name="RFC-14">{{استشهاد مختصر|RFC 1970|ص=1|لغة=en}}</ref><ref name="RFC-15">{{استشهاد مختصر|RFC 1971|ص=1|لغة=en}}</ref> |
|||
في شهر ديسمبر من العام 1995، صدر المعيار الأصلي للإصدار السادس من بروتوكول الإنترنت تحت الاسم الرمزي RFC 1883.<ref name="RFC-11">{{استشهاد ويب |
|||
| الأخير= Deering |
|||
| الأول= S. |
|||
| الأخير2= Hinden |
|||
| الأول2= R. |
|||
| تاريخ= ديسمبر 1995 |
|||
| مسار أرشيف = https://web.archive.org/web/20191221175133/https://tools.ietf.org/html/rfc1883 |
|||
| مسار= https://tools.ietf.org/html/rfc1883 |
|||
| عنوان= RFC 1883, Internet Protocol, Version 6 (IPv6) Specification |
|||
| موقع=The Internet Society |
|||
| لغة= en |
|||
| doi = 10.17487/RFC1883 |
|||
| تاريخ الوصول= 30 مايو 2018 |
|||
|تاريخ أرشيف=2019-12-21}}</ref> وصدر معه أيضاً المعياران الأصليان لمُحددات بنية العناوين في الإصدار السادس ولبروتوكول رسائل التحكم للإصدار السادس، وحملت [[طلب تعليقات|وثائق طلب التعليقات]] الخاصة بهما الاسمان الرمزيان RFC 1884 وRFC 1885 على الترتيب.<ref name="RFC-12">{{استشهاد ويب |
|||
| الأخير= Hinden |
|||
| الأول= R. |
|||
| الأخير2= Deering |
|||
| الأول2= S. |
|||
| تاريخ= ديسمبر 1995 |
|||
| مسار أرشيف = https://web.archive.org/web/20200306033641/https://tools.ietf.org/html/rfc1884 |
|||
| مسار= https://tools.ietf.org/html/rfc1884 |
|||
| عنوان= RFC 1884, IP Version 6 Addressing Architecture |
|||
| لغة= en |
|||
| doi = 10.17487/RFC1884 |
|||
|تاريخ أرشيف=2020-03-06}}</ref><ref name="RFC-13">RFC 1885, P.1</ref> لاحقاً في شهر أغسطس من العام التالي، صدر المعياران الأصليان [[بروتوكول اكتشاف الجيران|لبروتوكول اكتشاف الجيران]] ولآلية التهيئة الذاتية الآلية، وحملا الاسمان الرمزيان على RFC 1970 وRFC 1971 على الترتيب.<ref name="RFC-14">{{استشهاد ويب |
|||
| الأخير= Narten |
|||
| الأول= T. |
|||
| الأخير2= Nordmark |
|||
| الأول2= E. |
|||
| الأخير3= Simpson |
|||
| الأول3= W. |
|||
| تاريخ= أغسطس 1996 |
|||
| مسار أرشيف = https://web.archive.org/web/20191204161326/https://tools.ietf.org/html/rfc1970 |
|||
| مسار= https://tools.ietf.org/html/rfc1970 |
|||
| عنوان= RFC 1970, Neighbor Discovery for IP Version 6 (IPv6) |
|||
| صفحة = 1 |
|||
| لغة= en |
|||
| doi = 10.17487/RFC1970 |
|||
|تاريخ أرشيف=2019-12-04}}</ref><ref name="RFC-15"> |
|||
{{استشهاد ويب |
|||
| الأخير= Thomson |
|||
| الأول= S. |
|||
| الأخير2= Narten |
|||
| الأول2= T. |
|||
| تاريخ= ديسمبر 1995 |
|||
| مسار أرشيف = https://web.archive.org/web/20191212101639/https://tools.ietf.org/html/rfc1971 |
|||
| مسار= https://tools.ietf.org/html/rfc1971 |
|||
| عنوان= RFC 1971, IPv6 Stateless Address Autoconfiguration |
|||
| لغة= en |
|||
| doi = 10.17487/RFC1971 |
|||
|تاريخ أرشيف=2019-12-12}}</ref> |
|||
صدرت مجموعة تحديثات جديدة تضمنت أربعة وثائق طلب تعليقات تمتد أسماؤها الرمزية من RFC 2460 حتى RFC 2463 في ديسمبر من العام 1998م، وشملت معاييرَ جديدةً للإصدار السادس، ولبروتوكول رسائل التحكم الخاص به ولبروتوكول اكتشاف الجيران ولآلية التهيئة الذاتية الآلية.<ref>{{ترقيم استشهادات| |
|||
|م1={{استشهاد مختصر|RFC 2460|ص=1|لغة=en}} |
|||
* RFC 2460, P.1 |
|||
|م2= {{استشهاد مختصر|RFC 2461|ص=1|لغة=en}} |
|||
|م3={{استشهاد مختصر|RFC 2462|ص=1|لغة=en}}}}</ref><ref name="RFC-19">{{استشهاد مختصر|RFC 2463|ص=1|لغة=en}}</ref> واستمرت التحديثات بالصدور منفصلة أو بشكل مجموعات، فصدرت ثلاث معايير متتابعة لبنية عناوين الإصدار السادس، آخرها في فبراير من العام 2006م، وحمل الاسم الرمزي RFC 4291،<ref name="RFC-20">{{استشهاد مختصر|RFC 4291|ص=1|لغة=en}}</ref> وصدر معيارٌ ثالث لبروتوكول رسائل التحكم للإصدار السادس في مارس من العام 2006م أيضًا، وحمل الاسم الرمزي RFC 4443،<ref name="RFC-21">RFC 4443, P.1</ref> وصدر ثالثًا زوجان من المعايير أحدهما لبروتوكول اكتشاف الجيران والآخر لآلية التهيئة الذاتية الآلية في فبراير 2007م وحملا الاسمين الرمزيين على RFC 4861 وRFC 4862 على الترتيب.<ref name="RFC-22">{{استشهاد مختصر|RFC 4861|ص=1|لغة=en}}</ref><ref name="RFC-23">{{استشهاد مختصر|RFC 4862|ص=1|لغة=en}}</ref> وأخيرًا صدر المعيار الحالي للإصدار السادس من بروتوكول الإنترنت في يونيو من العام 2017م وحمل الاسم الرمزي RFC 8200.<ref name="RFC-24">{{استشهاد مختصر|RFC 8200|ص=1|لغة=en}}</ref> |
|||
| الأخير= Narten |
|||
| الأول= T. |
|||
| الأخير2= Nordmark |
|||
| الأول2= E. |
|||
| الأخير3= Simpson |
|||
| الأول3= W. |
|||
| تاريخ= ديسمبر 1998 |
|||
| مسار أرشيف = https://web.archive.org/web/20200313111537/https://tools.ietf.org/html/rfc2461 |
|||
| مسار= https://tools.ietf.org/html/rfc2461 |
|||
| عنوان= RFC 2461, Neighbor Discovery for IP Version 6 (IPv6) |
|||
| لغة= en |
|||
| doi = 10.17487/RFC2461 |
|||
|تاريخ أرشيف=2020-03-13}} |
|||
* {{استشهاد ويب |
|||
| الأخير= Thomson |
|||
| الأول= S. |
|||
| الأخير2= Narten |
|||
| الأول2= T. |
|||
| تاريخ= ديسمبر 1998 |
|||
| مسار أرشيف = https://web.archive.org/web/20200507010551/https://tools.ietf.org/html/rfc2462 |
|||
| مسار= https://tools.ietf.org/html/rfc2462 |
|||
| عنوان= RFC 2462, IPv6 Stateless Address Autoconfiguration |
|||
| لغة= en |
|||
| doi = 10.17487/RFC2462 |
|||
|تاريخ أرشيف=2020-05-07}} |
|||
</ref><ref name="RFC-19"> |
|||
{{استشهاد ويب |
|||
| الأخير= Conta |
|||
| الأول= A. |
|||
| الأخير2= Deering |
|||
| الأول2= S. |
|||
| تاريخ= ديسمبر 1998 |
|||
| مسار أرشيف = https://web.archive.org/web/20200316000307/https://tools.ietf.org/html/rfc2463 |
|||
| مسار= https://tools.ietf.org/html/rfc2463 |
|||
| عنوان= RFC 2463, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification |
|||
| لغة= en |
|||
| doi = 10.17487/RFC2463 |
|||
|تاريخ أرشيف=2020-03-16}}</ref> واستمرت التحديثات بالصدور منفصلة أو بشكل مجموعات، فصدرت ثلاث معايير متتابعة لبنية عناوين الإصدار السادس، آخرها في فبراير من العام 2006م، وحمل الاسم الرمزي RFC 4291،<ref name="RFC-20">"RFC 4291, P.1</ref> وصدر معيارٌ ثالث لبروتوكول رسائل التحكم للإصدار السادس في مارس من العام 2006م أيضاً، وحمل الاسم الرمزي RFC 4443،<ref name="RFC-21">RFC 4443, P.1</ref> وصدر زوجٌ ثالث لبروتوكول اكتشاف الجيران ولآلية التهيئة الذاتية الآلية في فبراير 2007م وحملا الاسمان الرمزيان على RFC 4861 وRFC 4862 على الترتيب.<ref name="RFC-22">RFC 4861, P.1</ref><ref name="RFC-23">RFC 4862, P.1</ref> وأخيراً صدر المعيار الحالي للإصدار السادس من بروتوكول الإنترنت في يونيو من العام 2017م وحمل الاسم الرمزي RFC 8200.<ref name="RFC-24">RFC 8200, P.1</ref> |
|||
== مبدأ العمل == |
== مبدأ العمل == |
||
{{شريط جانبي بروتوكول الإنترنت}} |
{{شريط جانبي بروتوكول الإنترنت}} |
||
الإصدار السادس من بروتوكول الإنترنت هو [[بروتوكول (اتصالات)|بروتوكول]] [[تشبيك]] يعمل في [[طبقة الشبكة]] في [[نموذج الربط البيني للأنظمة المفتوحة]]، ويُشرف على مهام العنونة و[[تقطيع (شبكات)|تقطيع]] [[رزمة بيانات|رزم البيانات]] ويساهم في إدارة حركة البيانات في الإنترنت.<ref name="Book-4">{{استشهاد |
الإصدار السادس من بروتوكول الإنترنت هو [[بروتوكول (اتصالات)|بروتوكول]] [[تشبيك]] يعمل في [[طبقة الشبكة]] في [[نموذج الربط البيني للأنظمة المفتوحة]]، ويُشرف على مهام العنونة و[[تقطيع (شبكات)|تقطيع]] [[رزمة بيانات|رزم البيانات]] ويساهم في إدارة حركة البيانات في الإنترنت.<ref name="Book-4">{{استشهاد مختصر|Javvin|2005|ص=67|لغة=en}}</ref> صُمم الإصدار السادس من بروتوكول الإنترنت ليحل محل [[بروتوكول الإنترنت (الإصدار الرابع)|الإصدار الرابع]]، وليعالج المشكلات الناجمة عن استعماله والتي تتلخص بفضاء عناوين محدود الحجم وبنية [[ترويسة (حوسبة)|ترويسة]] معقدة ودعم محدود لإمكانية إضافة توسيعات جديدة للأصل. بالإضافة لمعالجة هذه المشكلات، فقد امتلك الإصدار السادس إمكانيات جديدة مثل إنشاء تدفقات من رزم البيانات وتمييزها بلافتات خاصة تتيح إمكانية لتقديم مستويات مختلفة من [[جودة الخدمة]]، ومثل دعم توسيعات جديدة اختيارية للمسائل الأمنية تشمل دعم [[مصادقة (حوسبة)|المصادقة]] و[[خصوصية|خصوصية البيانات]].<ref name="RFC-25">{{استشهاد مختصر|RFC 8200|ص=4|لغة=en}}</ref> |
||
|طبعة = الثانية |
|||
|مسار = https://archive.org/details/networkprotocolshandbook |
|||
|عنوان = Network Protocols Handbook |
|||
|سنة = 2005 |
|||
|ناشر = Javvin Technologies Inc. |
|||
|صفحة = 67 |
|||
|لغة = en |
|||
|تنسيق = PDF |
|||
| مسار أرشيف = https://web.archive.org/web/20200528153425/https://archive.org/details/networkprotocolshandbook | تاريخ أرشيف = 28 مايو 2020 }}</ref> صُمم الإصدار السادس من بروتوكول الإنترنت ليحل محل [[بروتوكول الإنترنت (الإصدار الرابع)|الإصدار الرابع]]، وليعالج المشكلات الناجمة عن استعماله والتي تتلخص بفضاء عناوين محدود الحجم وبنية [[ترويسة (حوسبة)|ترويسة]] معقدة ودعم محدود لإمكانية إضافة توسيعات جديدة للأصل. بالإضافة لمعالجة هذه المشكلات، فقد امتلك الإصدار السادس إمكانيات جديدة مثل إنشاء تدفقات من رزم البيانات وتمييزها بلافتات خاصة تتيح إمكانية لتقديم مستويات مختلفة من [[جودة الخدمة]]، ومثل دعم توسيعات جديدة اختيارية للمسائل الأمنية تشمل دعم [[مصادقة (معلوماتية)|التحقق من الهوية]] و[[خصوصية|خصوصية البيانات]].<ref name="RFC-25">RFC 8200, P.4</ref> |
|||
بشكل مشابه للإصدار الرابع، يقدم الإصدار السادس خدمتي العنونة والتقطيع.<ref name="Book-21"> |
بشكل مشابه للإصدار الرابع، يقدم الإصدار السادس خدمتي العنونة والتقطيع.<ref name="Book-21">{{استشهاد مختصر|Fall|2012|ص=184|لغة=en}}</ref> في ما يخص العنونة فإن الإصدار السادس من بروتوكول الإنترنت يُعرِّف فضاء عناوين يضم 2<sup>128</sup> عنوانًا، ويدعم ثلاثة أنماط من العنونة: هي عنونة [[بث فريد|البث فريد الوجهة]]، وعنونة [[بث متعدد الوجهات|البث المجموعاتي]] وعنونة [[بث نحو الأقرب|البث نحو الأقرب]]، أما [[بث عام (شبكات)|البث العام]] فهو غير مدعوم في هذا البروتوكول.<ref name="RFC-26">{{استشهاد مختصر|RFC 4291|ص=2-3|لغة=en}}</ref> في ما يخص التقطيع، يمكن للبروتوكول أن يقطع رزم بيانات الإصدار السادس في مصدرها فقط، وأن يعيد تجميع القطع في وجهتها النهائية فقط، ولا حاجة لتقطيع الرزم على طول المسار، وذلك لامتلاك مصدر رزم البيانات آليةً للتعرف على حجم [[وحدة النقل العظمى]] للمسار قبل البدء بالإرسال، ما يسمح له باختيار الحجم المناسب وتقطيع رزمة البيانات على أساسه.<ref name="RFC-27">{{استشهاد مختصر|RFC 8201|ص=1|لغة=en}}</ref> |
||
| الأخير= McCann |
|||
| الأول= J. |
|||
| الأخير2= Deering |
|||
| الأول2= S. |
|||
| الأخير3= Mogul |
|||
| الأول3= J. |
|||
| الأخير4= Hinden, Ed. |
|||
| الأول4= R. |
|||
| تاريخ= يوليو 2017 |
|||
| مسار أرشيف = https://web.archive.org/web/20200311235427/https://tools.ietf.org/html/rfc8201 |
|||
| مسار= https://tools.ietf.org/html/rfc8201 |
|||
| عنوان= RFC 8201, IPv6 Flow Label Specification |
|||
| لغة= en |
|||
| doi = 10.17487/RFC8201 |
|||
|تاريخ أرشيف=2020-03-11| ISSN = 2070-1721 |
|||
}}</ref> |
|||
أما |
أما في ما يخص إدارة حركة البيانات، يدعم البروتوكول آليتين منفصلتين هما الإدارة باستعمال تدفق البيانات والإدارة باستعمال صنف الخدمة. في ما يخص إنشاء تدفقات رزم البيانات، فهي آلية يدعمها للبروتوكول تسمح بتعريف مجموعة محددة رزم البيانات التي تُنقل بين مصدر لرزم البيانات ووجهة واحدة لها على الأقل. وتُعرِّف هذه الآلية التدفق بأنّه مجموعة من كلُ رزم البيانات التي تنتقل في اتجاه واحد عبر قناة اتصال مُحددة. ولا يلزم أن يكون المضيف الوجهة فريدًا فيمكن لهذه الآلية أن تدعم بالإضافة لرزم البث فريد الوجهة رزمَ البث المجموعاتي ورزمَ البث نحو الأقرب.<ref name="RFC-28">{{استشهاد مختصر|RFC 6437|ص=3|لغة=en}}</ref> تساعد عملية إنشاء تدفقات الرزم على تصنيف حركة البيانات وتقديم الخدمة المناسبة لها اعتمادًا على ترويسة بروتوكول الإصدار السادس فقط من غير الحاجة لترويسات الطبقات العليا.<ref name="RFC-29">{{استشهاد مختصر|RFC 6437|ص=7-10|لغة=en}}</ref> أما في ما يخص استعمال صنف الخدمة، فهي آلية مشابهة لما طُبِّق في الإصدار الرابع من البروتوكول، وفيها يُستعمل حقل صنف الخدمة لتعريف أصناف مختلفة من الخدمات المطلوبة، ويُصار بعدها إلى معالجة كل رزمة وتقديم الخدمات إليها وفقًا لقيمة هذا الحقل فيها.<ref name="RFC-30">{{استشهاد مختصر|RFC 2474|ص=1-2|لغة=en}}</ref> |
||
بالإضافة لذلك، تُعرِّف مُحددات البروتوكول المُصطلحات التالية وتستخدمها [[طلب تعليقات|وثائق طلب التعليقات]] ذات الصلة:<ref name="RFC-31">RFC 8200 |
بالإضافة لذلك، تُعرِّف مُحددات البروتوكول المُصطلحات التالية وتستخدمها [[طلب تعليقات|وثائق طلب التعليقات]] ذات الصلة:<ref name="RFC-31">{{استشهاد مختصر|RFC 8200|ص=5|لغة=en}}</ref> |
||
* '''عنوان البروتوكول:''' وهو مُعرِّف رقمي يخص [[طبقة الشبكة]] يُمكن أن يمُنح [[منفذ (عتاد)|لمنفذ]] واحد أو لعدة منافذ |
* '''عنوان البروتوكول:''' وهو مُعرِّف رقمي يخص [[طبقة الشبكة]] يُمكن أن يمُنح [[منفذ (عتاد)|لمنفذ]] واحد أو لعدة منافذ معًا. |
||
* '''العقدة:''' هي أي جهاز في الشبكة يُطبِّق البروتوكول. |
* '''العقدة:''' هي أي جهاز في الشبكة يُطبِّق البروتوكول. |
||
* '''الموجه:''' هو عقدة |
* '''الموجه:''' هو عقدة تنجز عملية [[توجيه (شبكات)|التوجيه]] لرزم بيانات لم تولدها للإصدار السادس من بروتوكول الإنترنت. |
||
* '''المُضيف:''' |
* '''المُضيف:''' هو أي عقدة ما خلا [[موجه (شبكات)|الموجهات]]. |
||
* '''الوصلة:''' |
* '''الوصلة:''' هي وسط اتصال على مستوى [[طبقة الوصلة]]، يمكن للعقد أن تتواصل بعضها مع بعض عبرها. |
||
* '''الجيران:''' بالنسبة لعقدة ما متصلة مع وصلة واحدة أو أكثر، فإنَّ الجيران هم جميع العقد التي تتصل مع تلك الوصلة أو الوصلات. |
* '''الجيران:''' بالنسبة لعقدة ما متصلة مع وصلة واحدة أو أكثر، فإنَّ الجيران هم جميع العقد التي تتصل مع تلك الوصلة أو الوصلات. |
||
سطر 258: | سطر 78: | ||
[[ملف:IPv6 headers sequence-ar.svg|تصغير|300بك|أمثلة متنوعة عن تتابع الترويسات في الإصدار السادس من بروتوكول الإنترنت.]] |
[[ملف:IPv6 headers sequence-ar.svg|تصغير|300بك|أمثلة متنوعة عن تتابع الترويسات في الإصدار السادس من بروتوكول الإنترنت.]] |
||
=== تتابع الترويسات === |
=== تتابع الترويسات === |
||
يُضيف الإصدار السادس من بروتوكول الإنترنت ترويسة خاصة به في عملية [[تغليف (شبكات)|التغليف]] عند إنشاء [[رزمة بيانات|رزمة البيانات]]، وطول هذه [[ترويسة (حوسبة)|الترويسة]] ثابت وهو 40 [[بايت]] |
يُضيف الإصدار السادس من بروتوكول الإنترنت ترويسة خاصة به في عملية [[تغليف (شبكات)|التغليف]] عند إنشاء [[رزمة بيانات|رزمة البيانات]]، وطول هذه [[ترويسة (حوسبة)|الترويسة]] ثابت وهو 40 [[بايت]] دائمًا.<ref name="RFC-32">{{استشهاد مختصر|RFC 8200|ص=7|لغة=en}}</ref> يمكن أيضًا أن تضاف معلومات أخرى تخصّ [[طبقة الشبكة]] في ترويسات خاصة تُسمَّى ترويسات التوسعة، تضاف بشكل اختياري بعد ترويسة بروتوكول الإصدار السادس، وقبل ترويسة بروتوكول الطبقة العليا. ولترويسات التوسعة أنواع هي: ترويسة خيارات المسار وترويسة القطعة وترويسة خيارات الوجهة وترويسة التوجيه وترويسة التحقق من الهوية وترويسة تأمين الحمولة بالتغليف.<ref name="RFC-33">{{استشهاد مختصر|RFC 8200|ص=9|لغة=en}}</ref> |
||
لكل نوع ترويسة مُعرِّف مُحدد، وتحتوي الترويسات جميعها، بما في ذلك ترويسة الإصدار السادس، على حقل مُخصص ليضم قيمة مُعرِّف نوع الترويسة التالية، ويسمح ذلك بإمكانية إنشاء تتابع من الترويسات، حيث تشير قيمة حقل المُعرِّف في كل ترويسة إلى نوع الترويسة التالية،<ref name="RFC-32"/> في حين تُخصص القيمة 59 للإشارة إلى عدم وجود ترويسة تالية وتستعمل في الترويسة الموجودة في نهاية التتابع.<ref name="Book-6"> |
لكل نوع ترويسة مُعرِّف مُحدد، وتحتوي الترويسات جميعها، بما في ذلك ترويسة الإصدار السادس، على حقل مُخصص ليضم قيمة مُعرِّف نوع الترويسة التالية، ويسمح ذلك بإمكانية إنشاء تتابع من الترويسات، حيث تشير قيمة حقل المُعرِّف في كل ترويسة إلى نوع الترويسة التالية،<ref name="RFC-32"/> في حين تُخصص القيمة 59 للإشارة إلى عدم وجود ترويسة تالية وتستعمل في الترويسة الموجودة في نهاية التتابع.<ref name="Book-6">{{استشهاد مختصر|Fall|2012|ص=194|لغة=en}}</ref><ref name="RFC-34">{{استشهاد مختصر|RFC 8200|ص=24|لغة=en}}</ref> تدير [[أيانا|هيئة أرقام الإنترنت المُخصصة]] ضبط القيم المعيارية لمُعرفات أنواع الترويسة.<ref group="Web"> |
||
{{استشهاد ويب |
{{استشهاد ويب |
||
| مسار أرشيف = https://web.archive.org/web/20200228001555/https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml |
| مسار أرشيف = https://web.archive.org/web/20200228001555/https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml |
||
سطر 268: | سطر 88: | ||
|تاريخ أرشيف= 28 فبراير 2020 |
|تاريخ أرشيف= 28 فبراير 2020 |
||
| تاريخ الوصول = 23 مايو 2020 |
| تاريخ الوصول = 23 مايو 2020 |
||
}}</ref> وإذا وردت عدة ترويسات، فتكون بالترتيب التالي:<ref name="RFC-35">RFC 8200 |
}}</ref> وإذا وردت عدة ترويسات، فتكون بالترتيب التالي:<ref name="RFC-35">{{استشهاد مختصر|RFC 8200|ص=10|لغة=en}}</ref>{{للهامش|1}} |
||
# ترويسة بروتوكول الإنترنت |
# ترويسة بروتوكول الإنترنت |
||
# ترويسة خيارات المسار |
# ترويسة خيارات المسار |
||
سطر 274: | سطر 94: | ||
# ترويسة التوجيه |
# ترويسة التوجيه |
||
# ترويسة القطعة |
# ترويسة القطعة |
||
# ترويسة |
# ترويسة تأمين الحمولة بالتغليف |
||
# ترويسة خيارات الوجهة (للخيارات التي ستُعالج في الوجهة النهائية فقط) |
# ترويسة خيارات الوجهة (للخيارات التي ستُعالج في الوجهة النهائية فقط) |
||
# ترويسة بروتوكول الطبقة العليا |
# ترويسة بروتوكول الطبقة العليا |
||
يجب أن يكون طول ترويسة التوسعة |
يجب أن يكون طول ترويسة التوسعة عددًا صحيحًا من مضاعفات 8 بايت، أي 16 و24 و32 إلخ ... وذلك ضروريٌ لمحاذاة الترويسات المتتابعة، وتضم بعض الترويسات عددًا من الخيارات التي يكون لها بنية محددة أيضًا بحيث تصطف وتُحاذَى تلقائيًَّا داخل الترويسة.<ref name="RFC-33"/> |
||
فيما خلا ترويسة خيارات المسار، لا تُعالَج أي ترويسة على طول مسار رزمة، ولا تضاف أي ترويسة لرزمة البيانات أو تحذف منها حتى تبلغ الرزمة العنوان المحدد بعنوان الوجهة في ترويسة البروتوكول.<ref name="RFC-36">RFC 8200 |
فيما خلا ترويسة خيارات المسار، لا تُعالَج أي ترويسة على طول مسار رزمة، ولا تضاف أي ترويسة لرزمة البيانات أو تحذف منها حتى تبلغ الرزمة العنوان المحدد بعنوان الوجهة في ترويسة البروتوكول.<ref name="RFC-36">{{استشهاد مختصر|RFC 8200|ص=8|لغة=en}}</ref>{{للهامش|2}} إنَّ وجود ترويسات التوسعة في رزمة بيانات ما هو مسألة اختيارية، أما دعمها فهو إلزامي في أي تنفيذ للإصدار السادس من البروتوكول،<ref name="RFC-33"/> ولكن توجد ترويسات أخرى مُعرَّفة لأغراض خاصة، لا يلزم أن تكون مدعومة في كل تنفيذ، منها على سبيل المثال ترويسة خيارات الحركة <ref name="RFC-37">{{استشهاد مختصر|RFC 6275|ص=49|لغة=en}}</ref> ترويسة {{وإو|بروتوكول هوية المضيف|Host Identity Protocol|en|بروتوكول هوية المضيف}}.<ref name="RFC-38">{{استشهاد مختصر|RFC 7401|ص=38|لغة=en}}</ref> |
||
| الأخير= Perkins, Ed. |
|||
| الأول= C. |
|||
| الأخير2= Johnson |
|||
| الأول2= D. |
|||
| الأخير3= Arkko |
|||
| الأول3= J. |
|||
| تاريخ= يوليو 2011 |
|||
| مسار أرشيف = https://web.archive.org/web/20200311155956/https://tools.ietf.org/html/rfc6275 |
|||
| صفحة = 49 |
|||
| مسار= https://tools.ietf.org/html/rfc6275 |
|||
| عنوان= RFC 6275, Mobility Support in IPv6 |
|||
| لغة= en |
|||
| doi = 10.17487/RFC6275 |
|||
|تاريخ أرشيف=2020-03-11|ISSN= 2070-1721 |
|||
}}</ref> ترويسة {{وإو|بروتوكول هوية المضيف|Host Identity Protocol|en|بروتوكول هوية المضيف}}.<ref name="RFC-38">{{استشهاد ويب |
|||
| الأخير= Moskowitz, Ed |
|||
| الأول= R. |
|||
| الأخير2= Heer |
|||
| الأول2= T. |
|||
| الأخير3= Jokela |
|||
| الأول3= P. |
|||
| الأخير4= Henderson |
|||
| الأول4= T. |
|||
| تاريخ= أبريل 2015 |
|||
| مسار أرشيف = https://web.archive.org/web/20200505132459/https://tools.ietf.org/html/rfc7401 |
|||
| مسار= https://tools.ietf.org/html/rfc7401 |
|||
| عنوان= RFC 7401, Host Identity Protocol Version 2 (HIPv2) |
|||
| لغة= en |
|||
| doi = 10.17487/RFC7401 |
|||
|تاريخ أرشيف=2020-05-05| صفحة = 38 |
|||
|ISSN= 2070-1721 |
|||
}}</ref> |
|||
=== بنى الترويسات === |
=== بنى الترويسات === |
||
سطر 318: | سطر 106: | ||
[[ملف:IPv6 header-ar.svg|تصغير|300بك|ترويسة الإصدار السادس من بروتوكول الإنترنت.]] |
[[ملف:IPv6 header-ar.svg|تصغير|300بك|ترويسة الإصدار السادس من بروتوكول الإنترنت.]] |
||
يبلغ طول [[ترويسة (حوسبة)|ترويسة]] الإصدار السادس 40 [[بايت]]، وتتكون من ثمانية حقول هي |
يبلغ طول [[ترويسة (حوسبة)|ترويسة]] الإصدار السادس 40 [[بايت]]، وتتكون من ثمانية حقول هي وفقًا لترتيب وردوها:<ref name="RFC-44">{{استشهاد مختصر|RFC 8200|ص=6-7|لغة=en}}</ref> |
||
* حقل '''رقم الإصدار''': وطوله 4 [[بت]]، ويمثل رقم الإصدار، وقيمته هي 6 |
* حقل '''رقم الإصدار''': وطوله 4 [[بت]]، ويمثل رقم الإصدار، وقيمته هي 6 دائمًا في ترويسة الإصدار السادس من بروتوكول الإنترنت. |
||
* حقل '''صنف حركة البيانات''': وطوله 8 بت، ويحتوي |
* حقل '''صنف حركة البيانات''': وطوله 8 بت، ويحتوي مُعرِّف رقمي يمكن ضبطه لتحديد جودة الخدمة التي ستحصل عليها رزمة البيانات. |
||
* حقل '''لافتة التدفق''': وطوله 20 بت، ويحتوي |
* حقل '''لافتة التدفق''': وطوله 20 بت، ويحتوي مُعرِّف رقمي يُحدد التدفق الذي تنتمي إليه رزمة البيانات، ويمكن أن تستعمل هذه القيمة في تحديد كيفية معالجة الرزمة في [[موجه (شبكات)|الموجهات]] التي تعالج الرزمة على طول المسار نحو وجهتها. |
||
* حقل '''طول الحمولة''': وطوله 16 بت، ويحتوي عدد [[عدد صحيح|صحيح]] [[عدد موجب|موجب]] يمثل طول حمولة الرزمة التي توجد فيها الترويسة |
* حقل '''طول الحمولة''': وطوله 16 بت، ويحتوي عدد [[عدد صحيح|صحيح]] [[عدد موجب|موجب]] يمثل طول حمولة الرزمة التي توجد فيها الترويسة مُقدرًا بالبايت، يشمل ذلك ترويسات التوسعة جميعها والتي تلي ترويسة الإصدار السادس. |
||
* حقل '''الترويسة التالية''': وطوله 8 بت، ويحدد نوع الترويسة التالية، التي تلي هذه الترويسة، إذا كانت الترويسة مغايرة لترويسات التوسعات، فإن قيم هذه الحقل مُطابقة للقيم المُستعملة في الإصدار الرابع من البروتوكول.<ref |
* حقل '''الترويسة التالية''': وطوله 8 بت، ويحدد نوع الترويسة التالية، التي تلي هذه الترويسة، إذا كانت الترويسة مغايرة لترويسات التوسعات، فإن قيم هذه الحقل مُطابقة للقيم المُستعملة في الإصدار الرابع من البروتوكول.<ref group="Web">{{استشهاد ويب |
||
| مسار أرشيف = https://web.archive.org/web/20200213184959/https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml |
| مسار أرشيف = https://web.archive.org/web/20200213184959/https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml |
||
| مسار= https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml |
| مسار= https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml |
||
سطر 331: | سطر 119: | ||
|تاريخ الوصول = 23 مايو 2020 |
|تاريخ الوصول = 23 مايو 2020 |
||
}}</ref> |
}}</ref> |
||
* حقل '''عدد القفزات''': وطوله 8 بت، ويحتوي |
* حقل '''عدد القفزات''': وطوله 8 بت، ويحتوي عددًا صحيحًا موجبًا. ينقص كل موجه يُعالج رزمة البيانات ويُوجِّههها واحدًا من هذه القيمة. يفحص كل موجه يستقبل رزمة البيانات قيمة هذا الحقل أولًا، إذا كانت مساوية للصفر، فإنه يتخلص منها. إذا استقبلت الوجهة النهائية الرزمة بقيمة صفرية لهذا الحقل، لا تتخلص منها بل تعالجها. |
||
* حقل '''عنوان المصدر''': وطوله 128 بت، عنوان العقدة المصدر التي ولدت رزمة البيانات. |
* حقل '''عنوان المصدر''': وطوله 128 بت، عنوان العقدة المصدر التي ولدت رزمة البيانات. |
||
* حقل '''عنوان الوجهة''': وطوله 128 بت، عنوان وجهة الرزمة. قد يحتوي عنوان الوجهة الأخيرة، أو عنوان المُستقبل التالي للرزمة إذا كانت ترويسة التوجيه موجودة بعد ترويسة البروتوكول. |
* حقل '''عنوان الوجهة''': وطوله 128 بت، عنوان وجهة الرزمة. قد يحتوي عنوان الوجهة الأخيرة، أو عنوان المُستقبل التالي للرزمة إذا كانت ترويسة التوجيه موجودة بعد ترويسة البروتوكول. |
||
سطر 337: | سطر 125: | ||
==== ترويسة خيارات المسار ==== |
==== ترويسة خيارات المسار ==== |
||
[[ملف:Hop-by-Hop and Destination option headers structure-ar.svg|300بك|تصغير|بنية ترويسة خيارات المسار]] |
[[ملف:Hop-by-Hop and Destination option headers structure-ar.svg|300بك|تصغير|بنية ترويسة خيارات المسار]] |
||
تستعمل ترويسة خيارات المسار {{إنج|Hop-by-hop options header}} لحمل معلومات لخيارات يُمكن فحصها أو معالجة محتواها في كل [[ |
تستعمل ترويسة خيارات المسار {{إنج|Hop-by-hop options header}} لحمل معلومات لخيارات يُمكن فحصها أو معالجة محتواها في كل [[موجه (شبكات)|مُوجِّه]] تمر به الرزمة عبر مسارها إلى وجهتها النهائية. إن قيمة النوع الخاصة بهذه الترويسة هي 0، وإذا وردت هذه الترويسة في رزمة بيانات، فيجب أن تُوضع هذه القيمة في حقل الترويسة التالية الموجود داخل الترويسة السابقة.<ref name="RFC-39">{{استشهاد مختصر|RFC 8200|ص=13|لغة=en}}</ref> |
||
طول ترويسة خيارات المسار مُتغيِّرٌ، وهي تتكون من حقلين ثابتي الطول يليهما حقل واحد مُتغيِّر الطول، وهذه الحقول هي |
طول ترويسة خيارات المسار مُتغيِّرٌ، وهي تتكون من حقلين ثابتي الطول يليهما حقل واحد مُتغيِّر الطول، وهذه الحقول هي وفقًا لترتيب ورودها:<ref name="RFC-39"/> |
||
* حقل '''الترويسة التالية''': طوله 8 [[بت]]، ويحتوي |
* حقل '''الترويسة التالية''': طوله 8 [[بت]]، ويحتوي قيمة تُعرِّف نوع الترويسة الموجودة مباشرةً بعد هذه الترويسة. |
||
* حقل '''طول ترويسة التوسعة''': وطوله 8 بت، ويحتوي |
* حقل '''طول ترويسة التوسعة''': وطوله 8 بت، ويحتوي عدد صحيح موجب يمثل طول ترويسة خيارات المسار بواحدة 8 [[بايت]]، دونَ احتساب البايتات الثمانية الأولى. مثلًا إذا كان طول الترويسة هو 16 بايت، فإن قيمة هذا الحقل هي 1، وإذا كان طول الترويسة هو 32 بايت فإن قيمة هذا الحقل هي 3. |
||
* حقل '''الخيارات''': مُتغيِّر الطول، يضم |
* حقل '''الخيارات''': مُتغيِّر الطول، يضم خيارًا واحدًا أو أكثر من خيارات المسار، ويلزم يكون طول هذا القسم متوافقًا مع واحدة 8 بايت، أي من المقبول أن يكون الطول: 8 أو 16 أو 24 بايت ... إلخ. |
||
{{تحديد}} |
{{تحديد}} |
||
==== ترويسة التوجيه ==== |
==== ترويسة التوجيه ==== |
||
[[ملف:Routing header structure-ar.svg|تصغير|300بك|بنية ترويسة التوجيه]] |
[[ملف:Routing header structure-ar.svg|تصغير|300بك|بنية ترويسة التوجيه]] |
||
يستعمل مصدر [[رزمة بيانات]] للإصدار السادس من بروتوكول الإنترنت ترويسة التوجيه {{إنج|Routing header}} لتحديد مسارها أو |
يستعمل مصدر [[رزمة بيانات]] للإصدار السادس من بروتوكول الإنترنت ترويسة التوجيه {{إنج|Routing header}} لتحديد مسارها أو جزءًا منه من خلال إضافة قائمة تضم عناوين العقد الوسيطية التي يلزم أن تزورها الرزمة عبر مسارها وصولًا إلى وجهتها.<ref name="Book-7">{{استشهاد مختصر|Fall|2012|ص=200|لغة=en}}</ref> تتشابه وظيفة هذه الترويسة مع وظيفة خيار المسار الحرّ من المصدر في [[بروتوكول الإنترنت (الإصدار الرابع)|الإصدار الرابع من بروتوكول الإنترنت]].<ref name="RFC-42">{{استشهاد مختصر|RFC 791|ص=16|لغة=en}}</ref> إن قيمة النوع الخاصّ بترويسة التوجيه هي 43، وإذا وردت هذه الترويسة في رزمة بيانات، فيجب أن تُوضع هذه القيمة في حقل الترويسة التالية الموجود داخل الترويسة السابقة.<ref name="RFC-40">{{استشهاد مختصر|RFC 8200|ص=14|لغة=en}}</ref> |
||
ترويسة التوجيه |
ترويسة التوجيه متغيرة الطول، وهي تتكون من أربعة حقول ثابتة الطول يليها حقل وحيد متغير الطول، وهذه الحقول هي وفقًا لترتيب ورودها:<ref name="RFC-40"/> |
||
* حقل '''الترويسة التالية''': طوله 8 [[بت]]، ويحتوي |
* حقل '''الترويسة التالية''': طوله 8 [[بت]]، ويحتوي قيمة تُعرِّف نوع الترويسة الموجودة مباشرةً بعد هذه الترويسة. |
||
* حقل '''طول ترويسة التوسعة''': طوله 8 بت، ويحتوي |
* حقل '''طول ترويسة التوسعة''': طوله 8 بت، ويحتوي عدد صحيح موجب يمثل طول ترويسة خيارات المسار بواحدة 8 [[بايت]]، دونَ احتساب البايتات الثمانية الأولى. |
||
* حقل '''نوع التوجيه''': طوله 8 بت، ويضمّ |
* حقل '''نوع التوجيه''': طوله 8 بت، ويضمّ مُعرفًا يُحدد نوع التوجيه، وتحدد [[أيانا|هيئة أرقام الإنترنت المُخصصة]] قائمة المُعرفات المدعومة من قبل البروتوكول ومعاني كلٍّ منها.<ref group="Web">{{استشهاد ويب |
||
| مسار أرشيف = https://web.archive.org/web/20200507123543/https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml |
| مسار أرشيف = https://web.archive.org/web/20200507123543/https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml |
||
| مسار = https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml |
| مسار = https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml |
||
سطر 361: | سطر 149: | ||
|تاريخ أرشيف= 7 مايو 2020 |
|تاريخ أرشيف= 7 مايو 2020 |
||
|تاريخ الوصول = 23 مايو 2020 |
|تاريخ الوصول = 23 مايو 2020 |
||
}}</ref> اعتمد النوع ذو القيمة 0 في المعيار الأصلي، لكنه أُبطل لأسباب أمنية.{{للهامش|3}}<ref name="RFC-41">{{استشهاد |
}}</ref> اعتمد النوع ذو القيمة 0 في المعيار الأصلي، لكنه أُبطل لأسباب أمنية.{{للهامش|3}}<ref name="RFC-41">{{استشهاد مختصر|RFC 5095|ص=3|لغة=en}}</ref> |
||
* حقل '''القطاعات المتبقية''': طوله 8 بت، ويضمّ معرِّفًا رقميًّا لعدد [[قطاع شبكي|قطاعات الشبكة]] الوسيطية{{للهامش|4}} التي يلزم زيارتها قبل الوصول إلى الوجهة النهائية، ولكنَّها لما تُزر بعدُ. |
|||
|الأخير= Abley |
|||
* حقل '''بيانات مُرتبطة بالنوع''': مُتغيِّر الطول، ويحتوي مجموعة واحدة أو أكثر من هياكل البيانات التي يكون طولها متوافقًا مع واحدة 8 بايت، لتكون نهايتها عند نهاية الترويسة دائمًا، أما بنية الهياكل، فهي تتحدد بنوع التوجيه. |
|||
|الأول= J. |
|||
|الأخير2= Savola |
|||
|الأول2= P. |
|||
|الأخير3= Neville-Neil |
|||
|الأول3= G. |
|||
| تاريخ= ديسمبر 2007 |
|||
| مسار أرشيف = https://web.archive.org/web/20200502205413/https://tools.ietf.org/html/rfc5095 |
|||
| مسار= https://tools.ietf.org/html/rfc5095 |
|||
| عنوان= RFC 5095, Deprecation of Type 0 Routing Headers in IPv6 |
|||
| موقع=The Internet Society |
|||
| صفحة = 3 |
|||
| لغة= en |
|||
|doi= 10.17487/RFC5095 |
|||
| تاريخ الوصول= 23 مايو 2020 |
|||
|تاريخ أرشيف=2020-05-02}}</ref> |
|||
* حقل '''القطاعات المتبقية''':طوله 8 بت، ويضمّ معرِّفاً رقمياً لعدد [[قطاع شبكي|قطاعات الشبكة]] الوسيطية{{للهامش|4}} التي يلزم زيارتها قبل الوصول إلى الوجهة النهائية، ولكنَّها لما تُزر بعدُ. |
|||
* حقل '''بيانات مُرتبطة بالنوع''': مُتغيِّر الطول، ويحتوي على مجموعة واحدة أو أكثر من هياكل البيانات التي يكون طولها متوافقاً مع واحدة 8 بايت، لتكون نهايتها عند نهاية الترويسة دائماً، أما بنية الهياكل، فهي تتحدد بتوع التوجيه. |
|||
توجد حالتان مرتبطتان بترويسة التوجيه تستوجبان إرسال رسائل أخطاء خاصَّة [[بروتوكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت|ببروتوكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت]]، وهما:<ref name="RFC-43">{{استشهاد مختصر|RFC 8200|ص=15|لغة=en}}</ref> |
|||
# إذا استقبلت عقدة ما، مغايرة للوجهة النهائية، رزمة بيانات تحتوي |
# إذا استقبلت عقدة ما، مغايرة للوجهة النهائية، رزمة بيانات تحتوي ترويسة التوجيه، وكان نوع التوجيه غيرَ معروف، ويجب عندها التخلص من الرزمة أيضًا قبل إرسال رسالة الخطأ. أما إذا كانت العقدة هي الوجهة النهائية، فتُهمل الترويسة وتعالج الرزمة. |
||
# إذا كان توجيه الرزمة |
# إذا كان توجيه الرزمة لازمًا عبر شبكة ما، ولكن حجمها أكبر من حجم وحدة النقل العظمى للشبكة، وعندها يجب على العقدة التي [[توجيه (شبكات)|تُوجِّه]] الرزمة أن تتخلص منها قبل أن ترسل رسالة الخطأ المناسبة إلى مصدر البروتوكول. |
||
==== ترويسة القطعة ==== |
==== ترويسة القطعة ==== |
||
[[ملف:Fragment header structure-ar.svg|تصغير|300بك|بنية ترويسة القطعة]] |
[[ملف:Fragment header structure-ar.svg|تصغير|300بك|بنية ترويسة القطعة]] |
||
تضاف ترويسة القطعة {{إنج|Fragment header}} إلى جميع القطع الناتجة عن عملية [[تقطيع (شبكات)|تقطيع]] رزمة بيانات.<ref name="RFC-45">RFC 8200 |
تضاف ترويسة القطعة {{إنج|Fragment header}} إلى جميع القطع الناتجة عن عملية [[تقطيع (شبكات)|تقطيع]] رزمة بيانات.<ref name="RFC-45">{{استشهاد مختصر|RFC 8200|ص=19|لغة=en}}</ref> إنَّ قيمة النوع الخاصة بهذه الترويسة هي 44، وإذا وردت هذه الترويسة في رزمة بيانات، فيجب أن تُوضع هذه القيمة في حقل الترويسة التالية الموجود داخل الترويسة السابقة.<ref group="Web">{{استشهاد ويب |
||
| مسار أرشيف = https://web.archive.org/web/20180104065343/https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml |
| مسار أرشيف = https://web.archive.org/web/20180104065343/https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml |
||
| تاريخ أرشيف = 4 يناير 2018 |
| تاريخ أرشيف = 4 يناير 2018 |
||
سطر 396: | سطر 168: | ||
| تاريخ الوصول= 18 يوليو 2018}}</ref> |
| تاريخ الوصول= 18 يوليو 2018}}</ref> |
||
يبلغ طول ترويسة القطعة 8 [[بايت]]، وتتألف من 6 حقول دائمة، هي |
يبلغ طول ترويسة القطعة 8 [[بايت]]، وتتألف من 6 حقول دائمة، هي وفقًا لترتيب وردوها:<ref name="RFC-47">{{استشهاد مختصر|RFC 8200|ص=15-16|لغة=en}}</ref> |
||
* حقل '''الترويسة التالية''': طوله 8 [[بت]]، ويضبط بشكل مشابه لحقل الترويسة التالية في ترويسة البروتوكول الأصلية. |
* حقل '''الترويسة التالية''': طوله 8 [[بت]]، ويضبط بشكل مشابه لحقل الترويسة التالية في ترويسة البروتوكول الأصلية. |
||
* حقل '''محجوز''' طوله 8 بت، يُضبط إلى قيمة صفرية في مصدر الرزمة عند الإرسال. |
* حقل '''محجوز''' طوله 8 بت، يُضبط إلى قيمة صفرية في مصدر الرزمة عند الإرسال. |
||
* حقل '''إزاحة القطعة''': طوله 13 بت، يحتوي |
* حقل '''إزاحة القطعة''': طوله 13 بت، يحتوي موقع حمولة القطعة النسبي ضمن حمولة الرزمة الأصلية، وتعبر قيمة الرقم الموجود عن الإزاحة بواحدة هي 8 بايت، فإذا كانت قيمة هذا الحقل مثلًا هي 2، فإن إزاحة القطعة الحقيقية هي 16 بايت. |
||
* حقل '''محجوز''' طوله 2 بت، يُضبط إلى قيمة صفرية في مصدر الرزمة عند الإرسال. |
* حقل '''محجوز''' طوله 2 بت، يُضبط إلى قيمة صفرية في مصدر الرزمة عند الإرسال. |
||
* '''علم المزيد من القطع''': طوله 1 بت، ويستخدم للإشارة إلى القطعة الأخيرة، إذا كانت قيمته 1، فهذا يعني |
* '''علم المزيد من القطع''': طوله 1 بت، ويستخدم للإشارة إلى القطعة الأخيرة، إذا كانت قيمته 1، فهذا يعني وجود قطع لاحقة نتجت عن عملية التقطيع، أما إذا كانت قيمته 0 فذلك يعني بأنَّ هذه القطعة هي القطعة الأخيرة. |
||
* حقل '''مُعرّف القطعة''' 32 بت، وهي يحتوي قيمة فريدة تُميّز الرزمة الأصلية وجميع القطع التي نتجت عن تقطيعها. |
* حقل '''مُعرّف القطعة''' طوله 32 بت، وهي يحتوي قيمة فريدة تُميّز الرزمة الأصلية وجميع القطع التي نتجت عن تقطيعها. توجد [[خوارزمية|خوارزميات]] عديدة لاختيار قيمة المعرّف بحيث يكون فريدًا وآمنًا، وهي موصوفة في [[طلب تعليقات|وثيقة طلب التعليقات]] RFC 7739.<ref name="RFC-46">{{استشهاد مختصر|RFC 7739|ص=1|لغة=en}}</ref> |
||
| الأخير= Gont |
|||
| الأول= F. |
|||
| تاريخ= فبراير 2016 |
|||
| مسار أرشيف = https://web.archive.org/web/20200528152556/https://www.ietf.org/rfc/rfc7739/ |
|||
| مسار= https://www.ietf.org/rfc/rfc7739 |
|||
| عنوان= RFC 7739, Security Implications of Predictable Fragment Identification Values |
|||
| موقع= The Internet Society |
|||
| لغة= en |
|||
| issn = 2070-1721 |
|||
| تاريخ الوصول= 17 يوليو 2018|تاريخ أرشيف=2020-05-28| وصلة مكسورة = yes }}</ref> |
|||
==== ترويسة خيارات الوجهة ==== |
==== ترويسة خيارات الوجهة ==== |
||
[[ملف:Hop-by-Hop and Destination option headers structure-ar.svg|300بك|تصغير|بنية ترويسة خيارات الوجهة.]] |
[[ملف:Hop-by-Hop and Destination option headers structure-ar.svg|300بك|تصغير|بنية ترويسة خيارات الوجهة.]] |
||
تُستخدم ترويسة خيارات الوجهة {{إنج|Destination Options Header}} لحمل الخيارات التي تُعالجها الوجهة النهائية للرزمة فقط. إنَّ قيمة النوع الخاصّ بترويسة التوجيه هي 60، وإذا وردت هذه الترويسة في [[رزمة بيانات]]، فيجب أن تُوضع هذه القيمة في حقل الترويسة التالية الموجود داخل الترويسة السابقة.<ref name="RFC-48">RFC 8200 |
تُستخدم ترويسة خيارات الوجهة {{إنج|Destination Options Header}} لحمل الخيارات التي تُعالجها الوجهة النهائية للرزمة فقط. إنَّ قيمة النوع الخاصّ بترويسة التوجيه هي 60، وإذا وردت هذه الترويسة في [[رزمة بيانات]]، فيجب أن تُوضع هذه القيمة في حقل الترويسة التالية الموجود داخل الترويسة السابقة.<ref name="RFC-48">{{استشهاد مختصر|RFC 8200|ص=23|لغة=en}}</ref> |
||
ترويسة خيارات الوجهة |
ترويسة خيارات الوجهة مُتغيَّرة الطول، وهي تتكون من حقلين ثابتي الطول يليهما حقل وحيد متغير الطول، وهذه الحقول هي وفقًا لترتيب ورودها:.<ref name="RFC-48"/> |
||
* حقل '''الترويسة التالية''': طوله 8 [[بت]]، ويحتوي |
* حقل '''الترويسة التالية''': طوله 8 [[بت]]، ويحتوي قيمة تُعرِّف نوع الترويسة الموجودة مباشرةً بعد هذه الترويسة. |
||
* حقل '''طول ترويسة التوسعة''': وطوله 8 بت، ويحتوي |
* حقل '''طول ترويسة التوسعة''': وطوله 8 بت، ويحتوي عدد صحيح موجب يمثل طول ترويسة خيارات المسار بواحدة 8 [[بايت]]، دونَ احتساب البايتات الثمانية الأولى. |
||
* حقل '''الخيارات''': متغيِّر الطول، يضم |
* حقل '''الخيارات''': متغيِّر الطول، يضم خيارًا واحدًا أو أكثر من خيارات الوجهة، ويلزم أن يكون طول هذا القسم متوافقًا مع واحدة 8 بايت، أي من المقبول أن يكون الطول: 8 أو 16 أو 24 بايت ... إلخ. |
||
==== ترويسة |
==== ترويسة المصادقة ==== |
||
[[ملف:Authentcation header structure-ar.svg|تصغير|300بك|بنية ترويسة |
[[ملف:Authentcation header structure-ar.svg|تصغير|300بك|بنية ترويسة المصادقة.]] |
||
تُؤَمِّن ترويسة |
تُؤَمِّن ترويسة المصادقة {{إنج|Authentication Header}} آليةً للتحقق من سلامة [[رزمة بيانات|رزم البيانات]] المنقولة عبر اتصال يجري عبر قناة [[اتصال غير مهيأ|غير مُهيَّأة]] و[[مصادقة|تحققًا من هوية]] مصدر هذه الرزمة. تسمح آلية التحقق من السلامة بمنع تلاعب وسيط ما برزم البيانات عند حركتها بين مصدرها ووجهتها، وتستخدم في التصدي [[هجوم الوسيط|لهجمات الوسيط]].<ref name="RFC-49">{{استشهاد مختصر|RFC 4302|ص=3|لغة=en}}</ref> إنَّ قيمة النوع الخاصّ بترويسة المصادقة هي 51، وإذا وردت هذه الترويسة في رزمة بيانات، فيجب أن تُوضع هذه القيمة في حقل الترويسة التالية الموجود داخل الترويسة السابقة.<ref name="RFC-50">{{استشهاد مختصر|RFC 4302|ص=4|لغة=en}}</ref> |
||
ترويسة خيارات الوجهة مُتغيَّرة الطول، وهي تتكون من ستة حقول، خمسةٌ منها ثابتة الطول يليها حقل وحيد متغير الطول، وهذه الحقول هي |
ترويسة خيارات الوجهة مُتغيَّرة الطول، وهي تتكون من ستة حقول، خمسةٌ منها ثابتة الطول يليها حقل وحيد متغير الطول، وهذه الحقول هي وفقًا لترتيب ورودها:<ref name="RFC-51">{{استشهاد مختصر|RFC 4302|ص=5-9|لغة=en}}</ref> |
||
* حقل '''الترويسة التالية''': طوله 8 [[بت]]، ويحتوي |
* حقل '''الترويسة التالية''': طوله 8 [[بت]]، ويحتوي قيمة تُعرِّف نوع الترويسة الموجودة مباشرةً بعد هذه الترويسة. |
||
* حقل '''طول الحمولة''': طوله 8 بت، ويحتوي |
* حقل '''طول الحمولة''': طوله 8 بت، ويحتوي طول ترويسة التوسعة بواحدة 32 بت، أو 4 [[بايت]]، منقوصًا منها بايتان. أي إذا كان طول الترويسة هو 100 بايت، فإن قيمة هذا الحقل هي 2-(100/4)= 2-25 = 23. |
||
* حقل '''محجوز''': بطول 16 بت. |
* حقل '''محجوز''': بطول 16 بت. |
||
* حقل '''فهرس وسائط الأمن''': بطول 32 بت، ويحتوي مُعرِّف الجلسة الآمنة، وهي قيمة عشوائية يضيفها المصدر إلى الترويسة وتُستخدم من قبل الوجهة لتمييز الجلسة الآمنة التي أرسلت الرزمة عبرها. |
* حقل '''فهرس وسائط الأمن''': بطول 32 بت، ويحتوي مُعرِّف الجلسة الآمنة، وهي قيمة عشوائية يضيفها المصدر إلى الترويسة وتُستخدم من قبل الوجهة لتمييز الجلسة الآمنة التي أرسلت الرزمة عبرها. |
||
* حقل '''رقم التتابع''': بطول 32 بت، يحتوي |
* حقل '''رقم التتابع''': بطول 32 بت، يحتوي عداد تضبط قيمته في المصدر إلى قيمة محددة مع بدء الجلسة الآمنة، ثم قيمة التتابع بمقدار واحد مع كل رزمة بيانات تُرسل في الجلسة. |
||
* حقل '''قيمة التحقق من السلامة''': متغيِّر الطول، ويلزم أن يكون طوله من مضاعفات 32 بت، ويُضمُّ قيمة رياضية تُحسب في العقدة المصدر من أجل محتويات رزمة البيانات التي لا تتغير خلال عبورها الشبكة. في العقدة الوجهة، لا يمكن الحصول على قيمة حقل التحقق من السلامة نفسِها إلا إذا كانت محتويات الرزمة هي نفسُها، أي أنها وصلت من المصدر إلى الوجهة دونَ تلاعب فيها. |
* حقل '''قيمة التحقق من السلامة''': متغيِّر الطول، ويلزم أن يكون طوله من مضاعفات 32 بت، ويُضمُّ قيمة رياضية تُحسب في العقدة المصدر من أجل محتويات رزمة البيانات التي لا تتغير خلال عبورها الشبكة. في العقدة الوجهة، لا يمكن الحصول على قيمة حقل التحقق من السلامة نفسِها إلا إذا كانت محتويات الرزمة هي نفسُها، أي أنها وصلت من المصدر إلى الوجهة دونَ تلاعب فيها. |
||
==== ترويسة |
==== ترويسة تأمين الحمولة بالتغليف ==== |
||
[[ملف:Encapsulating Security Payload-ar.svg|تصغير|300بك|بنية ترويسة |
[[ملف:Encapsulating Security Payload-ar.svg|تصغير|300بك|بنية ترويسة تأمين الحمولة بالتغليف.]] |
||
تُستعمل ترويسة |
تُستعمل ترويسة تأمين الحمولة بالتغليف {{إنج|Encapsulating Security Payload header}} لتأمين مجموعة من خدمات الأمن التي تشمل: سرية البيانات وللتحقق من هوية مصدرها ولسلامة الاتصال عبر القنوات غير المُهيَّأة وللحماية من الهجمات المضادة لإعادة الإرسال {{إنج|Anti-replay attacks}}.<ref name="RFC-52">{{استشهاد مختصر|RFC 4303|ص=1|لغة=en}}</ref> إنَّ قيمة النوع الخاصّ بترويسة التوجيه هي 50، وإذا وردت هذه الترويسة في رزمة بيانات، فيجب أن تُوضع هذه القيمة في حقل الترويسة التالية الموجود داخل الترويسة السابقة.<ref name="RFC-53">{{استشهاد مختصر|RFC 4303|ص=5|لغة=en}}</ref> |
||
ترويسة |
ترويسة تأمين الحمولة بالتغليف مُتغيَّرة الطول، وهي تتكون من سبعة حقول، أربعة منها ثابتة الطول. وحقول هذه الترويسة هي وفقًا لترتيب ورودها:<ref name="RFC-54">{{استشهاد مختصر|RFC 4303|ص=10-17|لغة=en}}</ref> |
||
* حقل '''فهرس وسائط الأمن''': بطول 32 [[بت]]. ويحتوي مُعرِّف الجلسة الآمنة، وهي قيمة عشوائية يضيفها المصدر إلى الترويسة وتُستخدم من قبل الوجهة لتمييز الجلسة الآمنة التي أرسلت الرزمة عبرها. |
* حقل '''فهرس وسائط الأمن''': بطول 32 [[بت]]. ويحتوي مُعرِّف الجلسة الآمنة، وهي قيمة عشوائية يضيفها المصدر إلى الترويسة وتُستخدم من قبل الوجهة لتمييز الجلسة الآمنة التي أرسلت الرزمة عبرها. |
||
* حقل '''رقم التتابع''': بطول 32 بت. يحتوي |
* حقل '''رقم التتابع''': بطول 32 بت. يحتوي عداد تضبط قيمته الابتدائية في المصدر إلى قيمة محددة عند بدأ الجلسة الآمنة، ثم تُزاد قيمة التتابع بمقدار واحد مع كل رزمة بيانات يُرسلها مصدر الرزم في تلك الجلسة. |
||
* حقل '''بيانات الحمولة''': مُتغير الطول، يحتوي |
* حقل '''بيانات الحمولة''': مُتغير الطول، يحتوي المعلومات التي [[علم التعمية|تُعمَّى]] من أجل حمايتها. |
||
* حقل '''الحشو''': متغير الطول يتراوح طوله بين 0 و 255 [[بايت]]، يحتوي |
* حقل '''الحشو''': متغير الطول يتراوح طوله بين 0 و 255 [[بايت]]، يحتوي بايتات إضافية مُلحقة بالحمولة. يُضاف حقل الحشو لسببين: |
||
:# قد يلزم حد أدنى أو قيم محددة لطول البيانات المُراد |
:# قد يلزم حد أدنى أو قيم محددة لطول البيانات المُراد تعميتها. مثلًا، مضاعفات 4 أو 8 أو 16 بايت ... إلخ، وعندها تضاف بايتات الحشو لإكمال طول البيانات حتى القيمة اللازمة. |
||
:# قد يلزم إضافة عدة بايتات لجعل نهاية الحقلين التاليين تقع عند مضاعفات 4 بايت، وعندها تُضاف بايتات حشو حسب الحاجة لتحقيق ذلك. |
:# قد يلزم إضافة عدة بايتات لجعل نهاية الحقلين التاليين تقع عند مضاعفات 4 بايت، وعندها تُضاف بايتات حشو حسب الحاجة لتحقيق ذلك. |
||
* حقل '''طول الحشو''': طوله 8 بت، ويحتوي |
* حقل '''طول الحشو''': طوله 8 بت، ويحتوي عدد البايتات المُضافة في قسم الحشو. |
||
* حقل '''الترويسة التالية''': طوله 8 بت، ويحتوي |
* حقل '''الترويسة التالية''': طوله 8 بت، ويحتوي قيمة تُعرِّف نوع الترويسة الموجودة مباشرةً بعد هذه الترويسة. |
||
* حقل '''قيمة التحقق من السلامة''': متغيِّر الطول ويلزم أن يكون طوله من مضاعفات 32 بت، ويُضمُّ قيمة عددية تُحسب في العقدة المصدر من أجل محتويات رزمة البيانات التي لا تتغير خلال عبورها الشبكة. يعاد حساب هذه القيمة في العقدة الوجهة، ولا يمكن الحصول على القيمة نفسِها لحقل التحقق من السلامة إلا إذا كانت محتويات الرزمة هي نفسُها دون تغيير، ومعنى ذلك أنها وصلت من المصدر إلى الوجهة دونَ تلاعبٍ فيها. |
* حقل '''قيمة التحقق من السلامة''': متغيِّر الطول ويلزم أن يكون طوله من مضاعفات 32 بت، ويُضمُّ قيمة عددية تُحسب في العقدة المصدر من أجل محتويات رزمة البيانات التي لا تتغير خلال عبورها الشبكة. يعاد حساب هذه القيمة في العقدة الوجهة، ولا يمكن الحصول على القيمة نفسِها لحقل التحقق من السلامة إلا إذا كانت محتويات الرزمة هي نفسُها دون تغيير، ومعنى ذلك أنها وصلت من المصدر إلى الوجهة دونَ تلاعبٍ فيها. |
||
سطر 459: | سطر 221: | ||
=== بنية الخيارات === |
=== بنية الخيارات === |
||
[[ملف:IPv6 option structure-ar.svg|يسار|تصغير|300بك|بنية الخيار العامة في الإصدار السادس من بروتوكول الإنترنت.]] |
[[ملف:IPv6 option structure-ar.svg|يسار|تصغير|300بك|بنية الخيار العامة في الإصدار السادس من بروتوكول الإنترنت.]] |
||
يُمكن لترويستان من الترويسات التي تُعرِّفها محددات البروتوكول أن تحمل خياراتٍ مُختلفة العدد والحجم، وهما ترويستا خيارات المسار وخيارات الوجهة. إن بنية خيارات البروتوكول ثلاثية الحقول، وهي تتكون من البنية التالية:<ref name="Book-10"> |
يُمكن لترويستان من الترويسات التي تُعرِّفها محددات البروتوكول أن تحمل خياراتٍ مُختلفة العدد والحجم، وهما ترويستا خيارات المسار وخيارات الوجهة. إن بنية خيارات البروتوكول ثلاثية الحقول، وهي تتكون من البنية التالية:<ref name="Book-10">{{استشهاد مختصر|Fall|2012|ص=196|لغة=en}}</ref><ref name="RFC-55">{{استشهاد مختصر|RFC 8200|ص=11|لغة=en}}</ref> |
||
* حقل '''النوع''': طوله 8 [[بت]]، ويحتوي |
* حقل '''النوع''': طوله 8 [[بت]]، ويحتوي مُعرِّف رقمي يحدد نوع الخيار. |
||
* حقل '''الطول''': طوله 8 بت، ويحتوي طول الخيار |
* حقل '''الطول''': طوله 8 بت، ويحتوي طول الخيار مُقدرًا [[بايت|بالبايت]]. |
||
* حقل '''القيمة''': مُتغيِّر الطول، وتكون بنيته ومعاني القيم فيها مرتبطة بنوع الخيار. |
* حقل '''القيمة''': مُتغيِّر الطول، وتكون بنيته ومعاني القيم فيها مرتبطة بنوع الخيار. |
||
تُحدد قيمة البتان الأكثر أهمية في حقل النوع سلوك العقدة التي تُعالج الخيار إذا |
تُحدد قيمة البتان الأكثر أهمية في حقل النوع سلوك العقدة التي تُعالج الخيار إذا أخفق في التَّعرُّف على نوعه، فإذا كانت قيمتهما <sub>2</sub>(00) فعلى العقدة تخطي الخيار واستكمال معالجة الترويسة. وإذا كانت قيمتهما <sub>2</sub>(01) فعلى العقدة التخلُّص من الرزمة. وإذا كانت قيمتهما <sub>2</sub>(10) فعلى العقدة التخلص من الرزمة والاعتماد على بروتوكول رسائل التحكم للإصدار السادس لإرسال رسالة خطأ يُشير فيها إلى عدم إمكانية التعرف على نوع الخيار، وذلك بغض النظر عن كون مصدر الرزمة [[بث فريد|عنوان بث فريد الوجهة]] أو عنوان [[بث متعدد الوجهات|بث مجموعاتي]]. أما إذا كانت قيمتهما <sub>2</sub>(11) فعلى العقدة تنفيذ ما سبق فقط إذا لم يكن عنوان مصدر الرزمة عنوان بثِّ مجموعاتي.<ref name="RFC-55"/> أما البت الثالث من حيث الأهمية، فإن قيمته تحدد فيما إذا كان محتوى الخيار يتغير أثناء انتقال الرزمة عبر الشبكة. فإن كان المحتوى مُتغيرًا، كانت قيمة البت هي 1، وإن كان ثابتًا كانت قيمته 0.<ref name="RFC-56">{{استشهاد مختصر|RFC 8200|ص=12|لغة=en}}</ref> |
||
مع أن مُحددات البروتوكول تقدم دليلًا إرشاديًّا لتبيان كيفية تصميم خيارات للإصدار السادس من بروتوكول الإنترنت،<ref name="RFC-57">{{استشهاد مختصر|RFC 8200|ص=36-38|لغة=en}}</ref> إلا أن وثيقة مُحددات البروتكول لا تُعرِّف إلا خيارين اثنين فقط، هما خيار حشو بايتٍ واحد {{إنج|Pad1 option}}، وخيار حشو N بايت {{إنج|PadN option}}. ويُستخدمان لمحاذاة نهاية الخيار مع واحدة طول الترويسة، وهي 4 بايت. أي إذا كان طول الخيار مثلًا 11 بايتًا، فيضاف خيار حشو بايت وحيدٍ في النهاية، وإن كان 13 بايتًا يُضاف خيار حشوٍ لثلاث بايتات. وخيار حشو بايت واحد هو الخيار الوحيد الذي لا يتبع بنية الخيارات السابقة، بل يتكون من بايت وحيد صفريّ البتات.<ref name="RFC-58">{{استشهاد مختصر|RFC 8200|ص=12-13|لغة=en}}</ref> |
|||
<gallery> |
<gallery> |
||
Pad1 option structure-ar.svg| بنية خيار حشو بايت واحد |
Pad1 option structure-ar.svg| بنية خيار حشو بايت واحد |
||
PadN option structure-ar.svg| بنية خيار حشو N بايت |
PadN option structure-ar.svg| بنية خيار حشو N بايت |
||
</gallery> |
</gallery> |
||
== الوظائف == |
== الوظائف == |
||
=== العنونة === |
=== العنونة === |
||
==== تعاريف ==== |
==== تعاريف ==== |
||
تُعرِّف محددات البروتوكول فضاءً للعناوين، ويبلغ طول العنوان فيه 128 [[بت]]ًّا، ومعنى ذلك أن الفضاء يضمّ 2<sup>128</sup> عنوانًا أي ما يقارب 3.4x10<sup>38</sup> عنوانًا.<ref name="Book-11">{{استشهاد مختصر|Odom|2013|ص=579|لغة=en}}</ref><ref name="REF-AR2" group="ar">{{استشهاد مختصر|1=بكني|2=2022|ص=211}}</ref> تُمنح عناوين الإصدار السادس [[منفذ (عتاد)|للمنافذ]]، لا للعقد، ويمكن للمنفذ أن يستضيف أكثر من عنوان في الوقت نفسه. يدعم الإصدار السادس من بروتوكول الإنترنت ثلاثة أنماط لعنونة المنافذ هي عنونة [[بث فريد|البث فريد الوجهة]]، وعنونة البث المجموعاتي وعنونة [[بث نحو الأقرب|البث نحو الأقرب]]، ولا يدعم البروتوكول نمط عنونة [[بث عام (شبكات)|البث العام]]. في عنونة البث فريد الوجهة، يستضيف منفذ ما عنوانًا فريدًا، ويجري [[توجيه (شبكات)|توجيه]] الرزم المُرسلة نحو هذا العنوان إلى المنفذ الذي يستضيفه. أما في عنونة البث المجموعاتي، فتَستضيف مجموعة من المنافذ عنوانًا ما في الوقت نفسه، ويجري توجيه الرزم المُرسلة نحو ذلك العنوان إلى المنافذ التي تستضيفه جميعُها. أما في عنونة البث الأقرب، فتستضيف مجموعة من المنافذ عنوانًا ما في الوقت نفسه، ويجري توجيه الرزم المُرسلة نحو هذا العنوان إلى أقرب منفذ يستضيفه.{{للهامش|5}} إذا كان للعقدة منفذٌ وحيدٌ فقط يستضيف عنوان بثٍ فريد الوجهة فقط، يجوز أن يُستعمل العنوان مُعرِّفًا للعقدة.<ref name="RFC-26"/> |
|||
تُعرِّف محددات البروتوكول فضاءً للعناوين، ويبلغ طول العنوان فيه 128 [[بت|بتاً]]، ومعنى ذلك أن الفضاء يضمّ 2<sup>128</sup> عنواناً أي ما يقارب 3.4x10<sup>38</sup> عنواناً.<ref name="Book-11">Cisco CCENT/CCNA ICND1, P.579</ref> تُمنح عناوين الإصدار السادس [[منفذ (عتاد)|للمنافذ]]، لا للعقد، ويمكن للمنفذ أن يستضيف أكثر من عنوان في الوقت نفسه. يدعم الإصدار السادس من بروتوكول الإنترنت ثلاثة أنماط لعنونة المنافذ هي عنونة [[بث فريد|البث فريد الوجهة]]، وعنونة البث المجموعاتي وعنونة {{وإو|بث نحو الأقرب|Anycast|en|البث نحو الأقرب}}، ولا يدعم البروتوكول نمط عنونة [[بث عام (شبكات)|البث العام]]. في عنونة البث فريد الوجهة، يستضيف منفذ ما عنواناً فريداً، ويجري [[توجيه (شبكات)|توجيه]] الرزم المُرسلة نحو هذا العنوان إلى المنفذ الذي يستضيفه. أما في عنونة البث المجموعاتي، فتَستضيف مجموعة من المنافذ عنواناً ما في الوقت نفسه، ويجري توجيه الرزم المُرسلة نحو ذلك العنوان إلى المنافذ التي تستضيفه جميعُها. أما في عنونة البث الأقرب، فتستضيف مجموعة من المنافذ عنواناً ما في الوقت نفسه، ويجري توجيه الرزم المُرسلة نحو هذا العنوان إلى أقرب منفذ يستضيفه.{{للهامش|5}} إذا كان للعقدة منفذٌ وحيدٌ فقط يستضيف عنوان بثٍ فريد الوجهة فقط، يجوز أن يُستعمل العنوان كمُعرِّف للعقدة.<ref name="RFC-26"/> |
|||
==== التمثيل الرياضي ==== |
==== التمثيل الرياضي ==== |
||
[[ملف:IPv6 address terminology-ar.svg|تصغير|300بك|مسرد للمصطلحات المُستعملة في عناوين الإصدار السادس من بروتوكول الإنترنت]] |
[[ملف:IPv6 address terminology-ar.svg|تصغير|300بك|مسرد للمصطلحات المُستعملة في عناوين الإصدار السادس من بروتوكول الإنترنت]] |
||
يبلغ طول عنوان الإصدار السادس من بروتوكول الإنترنت 128 [[بت |
يبلغ طول عنوان الإصدار السادس من بروتوكول الإنترنت 128 [[بت]]ًّا، ويكون البت الواقع في أقصى اليسار هو البت ذو الأهمية العليا. يُكتب عنوان الإصدار السادس باستعمال [[نظام عد ستة عشري|نظام العد ست العشري]]، وتُمثَّل كل 4 بتات متتالية بخانة ستة عشرية واحدة تكون قيمتها حسب الجدول التالي: |
||
{| class="wikitable" |
{| class="wikitable" |
||
|+ جدول تحويل مباشر بين قيم نظامي العد الثنائي وستة العشري<ref name="Book-12"> |
|+ جدول تحويل مباشر بين قيم نظامي العد الثنائي وستة العشري<ref name="Book-12">{{استشهاد مختصر|Odom|2013|ص=617|لغة=en}}</ref> |
||
|- |
|- |
||
! قيمة البتات الأربعة<br/> بنظام العد الثنائي !! القيمة الموافقة بنظام<br/>العد ست العشري !! قيمة البتات الأربعة<br/> بنظام العد الثنائي !! القيمة الموافقة بنظام<br/>العد ست العشري |
! قيمة البتات الأربعة<br/> بنظام العد الثنائي !! القيمة الموافقة بنظام<br/>العد ست العشري !! قيمة البتات الأربعة<br/> بنظام العد الثنائي !! القيمة الموافقة بنظام<br/>العد ست العشري |
||
سطر 507: | سطر 265: | ||
|} |
|} |
||
[[ملف:IPv6 address stracture-ar.svg|تصغير|300بك|البنية العامة لعنوان بث فريد الوجهة في الإصدار السادس من بروتوكول الإنترنت.]] |
[[ملف:IPv6 address stracture-ar.svg|تصغير|300بك|البنية العامة لعنوان بث فريد الوجهة في الإصدار السادس من بروتوكول الإنترنت.]] |
||
تُسمَّى كل أربع خانات ستة عشرية متتالية رباعيةً {{إنج|Quartet}}،{{للهامش|7}} ويُفصل بين كل رباعيتين متتاليتين محرف النقطتين |
تُسمَّى كل أربع خانات ستة عشرية متتالية رباعيةً {{إنج|Quartet}}،{{للهامش|7}} ويُفصل بين كل رباعيتين متتاليتين محرف النقطتين الرأسيتين، أي ":"، وتكون الرباعية الواقعة في أقصى اليسار هي الأعلى أهمية.<ref name="Book-12"/> مثلًا العنوان التالي هو مثال عن عنوان من الإصدار السادس من بروتوكول الإنترنت: |
||
{{وسط|{{عنوان بروتوكول إنترنت في النسق|0123:4567:89ab:cdef:0123:4567:89ab:cdef}}}} |
{{وسط|{{عنوان بروتوكول إنترنت في النسق|0123:4567:89ab:cdef:0123:4567:89ab:cdef}}}} |
||
في عناوين البث فريد الوجهة، يتكون كل عنوان من قسمين، هما مُعرِّف الشبكة ومُعرِّف المنفذ. يكون مُعرِّف الشبكة |
في عناوين البث فريد الوجهة، يتكون كل عنوان من قسمين، هما مُعرِّف الشبكة ومُعرِّف المنفذ. يكون مُعرِّف الشبكة مُشترَكًا بين جميع العناوين التي تنتمي للفضاء الجزئي نفسه، أما مُعرِّف المنفذ فيكون مميزًا لكل منفذٍ على حدة. يُشتق كل عنوان بث فريد الوجهة انطلاقًا من بادئة ما، ويُستعمل طول تلك البادئة لتحديد الحد الفاصل بين مُعرِّف الشبكة ومُعرِّف المنفذ، فإذا كان طول بادئة ما 64 بتًّا، فهذا يعني أن مُعرِّف الشبكة يمتد على أربعٍ وستين بتًّا متتابعًا بدءًا من البت ذي الأهمية العليا وبشكلٍ غير مُنقطع، في حين يمتد مُعرِّف المنفذ على البتات الأربعة والستين المتبقية.<ref name="RFC-109">{{استشهاد مختصر|RFC 4291|ص=7|لغة=en}}</ref> |
||
تصف [[طلب تعليقات|وثيقة طلب التعليقات]] RFC 5952 الممارسات المُتبعة لتمثيل عناوين الإصدار السادس من بروتوكول الإنترنت بالشكل السليم، وتلخص |
تصف [[طلب تعليقات|وثيقة طلب التعليقات]] RFC 5952 الممارسات المُتبعة لتمثيل عناوين الإصدار السادس من بروتوكول الإنترنت بالشكل السليم، وتلخص عددًا من المُشكلات التي ترتبط بالمسألة مثل حالة الحروف كبيرة أو صغيرة واستعمال النقطتين الرأسيتين وغير ذلك وتطرح حلولًا لها.<ref name="RFC-60">{{استشهاد مختصر|RFC 5952|ص=2|لغة=en}}</ref> |
||
===== تمثيل العناوين والأقنعة ===== |
===== تمثيل العناوين والأقنعة ===== |
||
{|class="wikitable floatleft" |
{|class="wikitable floatleft" |
||
|- |
|- |
||
|+ أمثلة عن اختصار عناوين الإصدار السادس من بروتوكول الإنترنت <ref name="Book-13"> |
|+ أمثلة عن اختصار عناوين الإصدار السادس من بروتوكول الإنترنت <ref name="Book-13">{{استشهاد مختصر|Odom|2013|ص=619|لغة=en}}</ref> |
||
|- |
|- |
||
! العنوان المُكتمل !! العنوان المختصر |
! العنوان المُكتمل !! العنوان المختصر |
||
|- |
|- |
||
| style="text-align:center;"| {{عنوان بروتوكول إنترنت في النسق| |
| style="text-align:center;"| {{عنوان بروتوكول إنترنت في النسق|2340:0000:0010:0100:1000:abcd:0101:1010}} || style="text-align:center;"|{{عنوان بروتوكول إنترنت في النسق|2340:0:10:100:1000:abcd:101:1010}} |
||
|- style="text-align:center;" |
|- style="text-align:center;" |
||
|| 30A0:abcd:ef12:3456:0ABC:B0B0:9999:9009 || style="text-align:center;"| 30A0:abcd:ef12:3456:ABC:B0B0:9999:9009 |
|| 30A0:abcd:ef12:3456:0ABC:B0B0:9999:9009 || style="text-align:center;"| 30A0:abcd:ef12:3456:ABC:B0B0:9999:9009 |
||
سطر 530: | سطر 288: | ||
|} |
|} |
||
يُمثَّل عنوان الإصدار السادس من بروتوكول الإنترنت بثلاثة طرق:<ref name="Book-14">{{استشهاد مختصر|Odom|2013|ص=617-618|لغة=en}}</ref><ref name="RFC-61">{{استشهاد مختصر|RFC 4291|ص=4-5|لغة=en}}</ref> |
|||
* التمثيل المكتمل: وفيه يكتب العنوان |
* التمثيل المكتمل: وفيه يكتب العنوان كاملًا بالشكل #:#:#:#:#:#:#:#، وفيه يُمثل الرمز # أربع مراتب [[نظام عد ستة عشري|ستة عشرية]]. ومثاله العنوان:{{عنوان بروتوكول إنترنت في النسق|0123:4567:89ab:cdef:0123:4567:89ab:cdef}}. |
||
* التمثيل المُختصر: وفيه تختصر أجزاء من العنوان بالشكل التالي: |
* التمثيل المُختصر: وفيه تختصر أجزاء من العنوان بالشكل التالي: |
||
::# كانت المرتبة الأعلى أهميةً في رباعية ما صفرية لوحدها أو صفرية مع أكثر من مرتبة متتابعة معها، تهمل الأصفار وتُسقط من الكتابة |
::# كانت المرتبة الأعلى أهميةً في رباعية ما صفرية لوحدها أو صفرية مع أكثر من مرتبة متتابعة معها، تهمل الأصفار وتُسقط من الكتابة وتكتب المراتب الست عشرية غير الصفرية فقط، فمثلًا الرباعية 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:0:0:0:1234}} ولا يكتب {{عنوان بروتوكول إنترنت في النسق|1111::2222::1234}}. وأمَّا إذا كان طول التتابعين متساويًا، أمكن اختزال أحدهما دون تمييز. |
||
* التمثيل المُختلط: وهو تمثيل يُستعمل في الشبكات التي يستضيف المضيفون فيها عناوين من الإصدارين [[بروتوكول الإنترنت (الإصدار الرابع)|الرابع]] والسادس |
* التمثيل المُختلط: وهو تمثيل يُستعمل في الشبكات التي يستضيف المضيفون فيها عناوين من الإصدارين [[بروتوكول الإنترنت (الإصدار الرابع)|الرابع]] والسادس معًا، ويكون شكل العنوان d.d.d.d:#:#:#:#:#:#، حيث يُمثِّل الرمز # رباعيةً مكونة من 4 خانات ست عشرية غير صفرية، وتطبق قواعد الاختصار إذا وجدت خانات صفرية، أمَّا المحرف d فيُمثِّل خانة من خانات عنوان الإصدار الرابع من بروتوكول الإنترنت مكتوبة {{وإو|النظام العشري المنقط|Dot-decimal notation|en|بالنظام العشري المُنقَّط}}، ومثال هذا التمثيل العنوان: {{عنوان بروتوكول إنترنت في النسق|1111:0:0:0:0:0:200.100.10.1}} والذي يمكن أن يكتب بعد الاختصار بالشكل التالي: {{عنوان بروتوكول إنترنت في النسق|200.100.10.1::1111}}. |
||
===== تمثيل البادئات ===== |
===== تمثيل البادئات ===== |
||
البادئة {{إنج|Prefix}} هي فضاء جزئي من الفضاء الكلي لعناوين البروتوكول، وتُمثَّل كل بادئة بعنوان يُسمى عنوان البادئة. ويتشابه تمثيل البادئات في الإصدار السادس من بروتوكول الإنترنت مع تمثيلها في [[بروتوكول الإنترنت (الإصدار الرابع)|الإصدار الرابع]]، والذي أُقِرَّ بعد اعتماد آلية [[توجيه غير صنفي |
البادئة {{إنج|Prefix}} هي فضاء جزئي من الفضاء الكلي لعناوين البروتوكول، وتُمثَّل كل بادئة بعنوان يُسمى عنوان البادئة. ويتشابه تمثيل البادئات في الإصدار السادس من بروتوكول الإنترنت مع تمثيلها في [[بروتوكول الإنترنت (الإصدار الرابع)|الإصدار الرابع]]، والذي أُقِرَّ بعد اعتماد آلية [[توجيه بين نطاقي غير صنفي|التوجيه غير الصنفي بين النطاقات]].<ref name="RFC-66">{{استشهاد مختصر|RFC 4632|ص=5|لغة=en}}</ref> تتكون كل بادئة من جزئين، هما عنوان من الإصدار السادس من بروتوكول الإنترنت وطول البادئة، أي عدد البتات فيها، ويكون شكل البادئة:<ref name="RFC-63">{{استشهاد مختصر|RFC 4291|ص=5|لغة=en}}</ref> |
||
{{وسط|طول البادئة/عنوان الإصدار السادس}} |
{{وسط|طول البادئة/عنوان الإصدار السادس}} |
||
يمكن اختصار العنوان الموجود في البادئة |
يمكن اختصار العنوان الموجود في البادئة وفقًا لقواعد اختصار عناوين الإصدار السادس نفسها. فمثلًا، ما سيأتي هو أمثلة عن بادئات مكتوبة بشكل صحيح:<ref name="RFC-63"/> |
||
{{وسط|{{عنوان بروتوكول إنترنت في النسق|1111:0000:0000:2222:0000:0000:0000:0000/64}}}} |
{{وسط|{{عنوان بروتوكول إنترنت في النسق|1111:0000:0000:2222:0000:0000:0000:0000/64}}}} |
||
{{وسط|{{عنوان بروتوكول إنترنت في النسق|1111:0:0:2222:0:0:0:0/64}}}} |
{{وسط|{{عنوان بروتوكول إنترنت في النسق|1111:0:0:2222:0:0:0:0/64}}}} |
||
{{وسط|{{عنوان بروتوكول إنترنت في النسق|64/::1111:0:0:2222}}}} |
{{وسط|{{عنوان بروتوكول إنترنت في النسق|64/::1111:0:0:2222}}}} |
||
==== بنى العناوين |
==== بنى العناوين وفقًا لنمط التوجيه ==== |
||
{{أنماط التوجيه}} |
{{أنماط التوجيه}} |
||
يُعرِّف الإصدار السادس من بروتوكول الإنترنت فضاءً يضمُّ 2<sup>128</sup> |
يُعرِّف الإصدار السادس من بروتوكول الإنترنت فضاءً يضمُّ 2<sup>128</sup> عنوانًا فيه، ويدعم ثلاثة أنماط من العنونة هي العنونة هي عنونة البث الفريد الوجهة وعنونة البث المجموعاتي وعنونة البث نحو الأقرب.<ref name="RFC-26"/> يُخصص فضاء محجوز للبث المجموعاتي، ويُحجز فضاء خاص أيضًا لعناوين البث فريد الوجهة الوصلة المحلية، وفيما يخصص العنوان الصفري ليكون العنوان غير المُحدد والعنوان الذي يليه ليكون عنوان الحلقة العكسية، وفيما خلا ذلك، فما تبقى من الفضاء مُخصص لفضاء عناوين البث فريد الوجهة العالمي. ويبين الجدول التالي العناوين المحجوزة والأفضية الجزئية في الإصدار السادس من بروتوكول الإنترنت:<ref name="RFC-64">{{استشهاد مختصر|RFC 4291|ص=6|لغة=en}}</ref> |
||
{| class="wikitable" |
{| class="wikitable" |
||
سطر 570: | سطر 328: | ||
|} |
|} |
||
يجب الانتباه إلى أن عناوين البث نحو الأقرب تقتطع من أي فضاء من عناوين البث فريد الوجهة، لذلك لا يمكن التمييز بين عناوين الفضاءين |
يجب الانتباه إلى أن عناوين البث نحو الأقرب تقتطع من أي فضاء من عناوين البث فريد الوجهة، لذلك لا يمكن التمييز بين عناوين الفضاءين رقميًَّا، بل وفقًا لبنية العنوان ووظيفته.<ref name="RFC-64"/> |
||
===== عناوين البث فريد الوجهة ===== |
===== عناوين البث فريد الوجهة ===== |
||
عناوين [[بث فريد|البث فريد الوجهة]] هي العناوين التي تُمّيز [[منفذ (عتاد)| |
عناوين [[بث فريد|البث فريد الوجهة]] هي العناوين التي تُمّيز [[منفذ (عتاد)|منفذًا]] محددًا. إذا كان عنوان وجهة رزمة ما هو عنوان بث فريد الوجهة، [[توجيه (شبكات)|فستُوجَّه]] الرزمة نحو المنفذ الذي يستضيف هذا العنوان. تمتاز عناوين هذا الفضاء بإمكانية تجميعها معًا وتمثيلها كأفضية جزئية باستعمال تدوين البادئة بشكل مُشابه لتمثيل الأفضية الجزئية في [[بروتوكول الإنترنت (الإصدار الرابع)|الإصدار الرابع من بروتوكول الإنترنت]].<ref name="RFC-64"/> |
||
توجد أنواع عديدة لعناوين الفضاء فريد الوجهة منها، هي: |
|||
* '''العنوان غير المُحدد''' {{إنج|The Unspecified Address}}: هو العنوان الصفريّ، أي {{عنوان بروتوكول إنترنت في النسق|0:0:0:0:0:0:0:0}} أو |
* '''العنوان غير المُحدد''' {{إنج|The Unspecified Address}}: هو العنوان الصفريّ، أي {{عنوان بروتوكول إنترنت في النسق|0:0:0:0:0:0:0:0}} أو اختصارًا {{عنوان بروتوكول إنترنت في النسق|::}}. يُستعمل للدلالة إلى عدم استضافة المنفذ لعنوان من الإصدار السادس من بروتوكول إنترنت رغم وجود دعم للبروتوكول فيه، لذلك لا يجب أن يُمنح هذا العنوان لأي منفذ. لا يُستعمل هذا العنوان كعنوان وجهة لرزم البيانات، ويلزم أن تتخلص [[موجه (شبكات)|المُوجِّهات]] أي [[رزمة بيانات|رزمة]] مُوجَّهة نحو هذا العنوان.<ref name="RFC-67">{{استشهاد مختصر|RFC 4291|ص=9|لغة=en}}</ref> |
||
* '''عنوان الحلقة العكسية''' {{إنج|The Loopback Address}}: وهو العنوان {{عنوان بروتوكول إنترنت في النسق|0:0:0:0:0:0:0:1}} أو |
* '''عنوان الحلقة العكسية''' {{إنج|The Loopback Address}}: وهو العنوان {{عنوان بروتوكول إنترنت في النسق|0:0:0:0:0:0:0:1}} أو اختصارًا {{عنوان بروتوكول إنترنت في النسق|1::}}، ويُمكن أن يستخدم من قبل أي عقدة لإرسال رزم بيانات إلى نفسها، لذلك لا يجب أن يُمنح هذا العنوان لأي منفذ مادي. لا يُستعمل هذا العنوان كعنوان مصدر للرزم التي ستغادر عقدة ما، ولا يجب أن تُوجَّه الرزم التي تكون وجهتها عنوان الحلقة العكسية نحو خارج العقدة. ويلزم أن تتخلص الموجهات أي رزمة موجهة نحو عنوان الحلقة العكسية.<ref name="RFC-67"/> |
||
* '''عناوين البث فريد الوجهة العالمي''' {{إنج|Global Unicast Address}}: وتُستخدم لعنونة منفذ ما على الإنترنت بشكلٍ فريدٍ على مستوى العالم. يتكون العنوان من ثلاثة حقول: حقل بادئة التوجيه العالمية، وهي تمنح للموقع الذي يُشغل المنفذ بحسب هرمية تحصيص رباعية المستويات تديرها [[أيانا|هيئة أرقام الإنترنت المُخصصة]]، |
* '''عناوين البث فريد الوجهة العالمي''' {{إنج|Global Unicast Address}}: وتُستخدم لعنونة منفذ ما على الإنترنت بشكلٍ فريدٍ على مستوى العالم. يتكون العنوان من ثلاثة حقول: حقل بادئة التوجيه العالمية، وهي تمنح للموقع الذي يُشغل المنفذ بحسب هرمية تحصيص رباعية المستويات تديرها [[أيانا|هيئة أرقام الإنترنت المُخصصة]]، وحقل مُعرف الشبكة الجزئية والذي يَضبطه مشغلو الموقع، حيث يوجد المنفذ، وذلك بهدف [[تجزئة الشبكة|تجزئة]] الفضاء الممنوح إلى أفضية جزئية أصغر حجمًا لأغراض إدارية أو تنظيمية.<ref name="RFC-67"/> |
||
: في عناوين البث فريد الوجهة العالمية التي لا تكون قيمة [[بت|البتات]] ذات الأهمية العليا فيها <sub>2</sub>(000)، يكون مجموع طولي حقلي بادئة التوجيه العالمية |
: في عناوين البث فريد الوجهة العالمية التي لا تكون قيمة [[بت|البتات]] ذات الأهمية العليا فيها <sub>2</sub>(000)، يكون مجموع طولي حقلي بادئة التوجيه العالمية ومُعرِّف الشبكة الجزئية 64 بت، ما يترك 64 بتًّا لمُعرف المنفذ، وبهذا تتوافق بنية هذه العناوين مع آلية التهيئة الذاتية الآلية. أما العناوين التي تكون قيمة البتات ذات الأهميةً العليا فيها <sub>2</sub>(000) فهي لا تُلزَم بالبنية السابقة.<ref name="RFC-68">{{استشهاد مختصر|RFC 4291|ص=10|لغة=en}}</ref> وفي ما يأتي مثالٌ عن هذا العنوان: {{عنوان بروتوكول إنترنت في النسق|{{وسط|1::2001:1111:2222:3333}}}} |
||
* '''عناوين البث فريد الوجهة في الوصلة المحلية''' {{إنج|Link-Local Unicast Address}}: ويشغل الفضاء fe80::/10،<ref name="Book-16"> |
* '''عناوين البث فريد الوجهة في الوصلة المحلية''' {{إنج|Link-Local Unicast Address}}: ويشغل الفضاء fe80::/10،<ref name="Book-16">{{استشهاد مختصر|Odom|2013|ص=634|لغة=en}}</ref> تُستخدم عناوين هذا الفضاء على مستوى الوصلة المحلية فقط، وهي مصممة لتخدم أغراضًا مثل التهيئة الآلية للعنوان واكتشاف الجيران. لا يجب على المُوجِّهات توجيه أي رزمة بيانات يكون عنوان مصدرها أو وجهتها عنوان وصلة محلية.<ref name="RFC-69">{{استشهاد مختصر|RFC 4291|ص=11|لغة=en}}</ref> |
||
: يتكون عنوان الوصلة المحلية من ثلاثة حُقول: الحقل الأول هو مُعرِّف فضاء عناوين الوصلة المحلية، وطوله 10 بتات وقيمته <sub>2</sub>(1111111010)، أما الحقل الثاني فهو حقل صفري يبلغ طوله 54 |
: يتكون عنوان الوصلة المحلية من ثلاثة حُقول: الحقل الأول هو مُعرِّف فضاء عناوين الوصلة المحلية، وطوله 10 بتات وقيمته <sub>2</sub>(1111111010)، أما الحقل الثاني فهو حقل صفري يبلغ طوله 54 بتًّا، والحقل الثالث هو حقل مُعرف المنفذ، ويُستخدم لتمييز المنفذ بشكل فريد على مستوى الوصلة المحلية.<ref name="RFC-69"/> وفي ما يأتي مثالٌ عن هذا العنوان: {{عنوان بروتوكول إنترنت في النسق|{{وسط|fe80::1ff:fe01:101}}}} |
||
* '''عناوين البث فريد الوجهة الفريد المحلي''' {{إنج|Unique Local IPv6 Unicast Addresses}}: حُجر له الفضاء {{عنوان بروتوكول إنترنت في النسق|fc00::/7}}،<ref name="Book-15"> |
* '''عناوين البث فريد الوجهة الفريد المحلي''' {{إنج|Unique Local IPv6 Unicast Addresses}}: حُجر له الفضاء {{عنوان بروتوكول إنترنت في النسق|fc00::/7}}،<ref name="Book-15">{{استشهاد مختصر|Odom|2013|ص=632|لغة=en}}</ref> ويُستخدم من أجل عنونة منفذ بشكل فريد على المستوى العالمي، ولكن من أجل إنشاء اتصالات محلية فقط، ولذلك لا يمكن توجيه الرزم المعنونة بهذه العناوين خارج الموقع الذي ولِّدت فيه.<ref name="RFC-70">{{استشهاد مختصر|RFC 4293|ص=2|لغة=en}}</ref> |
||
: يتألف العنوان الفريد المحلي من 5 حقول، أولها هو حقل البادئة وطوله 7 بتات وقيمته هي <sub>2</sub>(1111110) |
: يتألف العنوان الفريد المحلي من 5 حقول، أولها هو حقل البادئة وطوله 7 بتات وقيمته هي <sub>2</sub>(1111110) دائمًا، ويليه بت المحلية، ويُضبط إلى القيمة 1 دائمًا للإشارة إلى أن العنوان قد وُلِّد محليًّا،{{للهامش|8}} ثُمَّ حقل المُعرِّف العالمي وطوله 40 بتًّا، وهو مُعرِّف فريد على مستوى العالم يضبط محليًّا إلى قيمة عشوائية، ثُمّ حقل مُعرِّف الشبكة الجزئية طوله 16 بت، وهو حقل مخصص لمديري الشبكة لإتاحة إمكانية إنشاء شبكات جزئية، وأخيرًا مُعرِّف المنفذ وطوله 64 بتًّا، ويميز كل منفذ على حدته بشكل فريد.<ref name="RFC-71">{{استشهاد مختصر|RFC 4293|ص=3-4|لغة=en}}</ref> وفي ما يأتي مثالٌ عن هذا العنوان: [https://web.archive.org/web/20200323121229/https://www.ripe.net/participate/member-support/lir-basics/ipv6_reference_card.pdf مرجع] {{عنوان بروتوكول إنترنت في النسق|{{وسط|fdf8:f53b:82e4::53}}}} |
||
* '''عناوين البث فريد الوجهة المحلي في الموقع''' {{إنج|Site-Local Unicast Address}}: وهو صنف مُبطَل من عناوين البث فريد الوجهة.<ref name="RFC-72">{{استشهاد مختصر|RFC 3879|ص=1|لغة=en}}</ref> طُوِّر في الأصل ليَخدُم غرض العنونة داخل موقع ما دون الحاجة لبادئات عالمية. حُجر له الفضاء {{عنوان بروتوكول إنترنت في النسق|fec::/10}}،<ref name="Book-15"/> كانت بنية هذه العناوين مكونة من ثلاثة حقول: الحقل الأول هو معرف فضاء العناوين المحلية في الموقع، وطوله 10 بتات وقيمته <sub>2</sub>(1111111011)، أما الحقل الثاني فهو مُعرِّف الشبكة الجزئية، ويضبطه مشرفو الموقع حسب الحاجة، وأما الحقل الثالث فهو مُعرِّف المنفذ ويبلغ طوله 64 بتًّا.<ref name="RFC-69"/> وفي ما يأتي مثالٌ عن هذا العنوان: {{عنوان بروتوكول إنترنت في النسق|{{وسط|fec0::1234:5678:9abc}}}} |
|||
* '''عناوين البث فريد الوجهة المحلي في الموقع''' {{إنج|Site-Local Unicast Address}}: وهو صنف مُبطَل من عناوين البث فريد الوجهة.<ref name="RFC-72">{{استشهاد ويب |
|||
* ''' عناوين البث فريد الوجهة التي تتضمن عناوين من الإصدار الرابع''': يوجد عنوانان من عناوين البث فريد الوجهة في الإصدار السادس يحملان في البتات الاثنين والثلاثين ذات الأهمية الدنيا عناوين من الإصدار الرابع من بروتوكول الإنترنت وهما: |
|||
| الأخير= Huitema |
|||
:* '''عناوين البث فريدة الوجهة المُتوافِقة مع الإصدار الرابع''' {{إنج|IPv4-Compatible Unicast Address}}: عُرِّفت هذه العناوين في الأصل لتساهم في دعم عملية الانتقال من استعمال الإصدار الرابع إلى الإصدار السادس من بروتوكول الإنترنت. يتكون هذا العنوان بدءًا من الخانة الأكثر أهمية من 80 صفرًا يليها عنوان الإصدار الرابع من بروتوكول الإنترنت الذي يلزم أن يكون فريدًا عالميًّا.<ref name="RFC-68"/> |
|||
| الأول= C. |
|||
:: تُستخدم الطريقة الهجينة لتمثيل هذه العناوين. أبطلت طريقة الانتقال التي تستعمل هذه العناوين، ولذلك لم تعد هذه العناوين قيد الاستخدام.<ref name="RFC-68"/> وفي ما يأتي مثالٌ عن هذا العنوان: {{عنوان بروتوكول إنترنت في النسق|{{وسط|200.100.10.1::}}}} |
|||
| الأخير2= Carpenter |
|||
:* '''عناوين البث فريدة الوجهة المُقترنة مع الإصدار الرابع''' {{إنج| IPv4-Mapped Unicast Address}} وتستعمل لحمل عنوان الإصدار الرابع من بروتوكول الإنترنت الذي تستضيفه العقدة التي تدعم الإصدار السادس أيضًا.<ref name="RFC-68"/> وصفت طريقة استعمال هذا العنوان في وثيقة طلب التعليقات RFC 4038،<ref name="RFC-75">{{استشهاد مختصر|RFC 4038|ص=1|لغة=en}}</ref> وهو يتكون من ثلاثة حقول بدءًا من الخانة الأكثر أهمية هي 80 صفرًا متتاليًّا في الحقل الأول، يليها 16 واحدًا متتاليًّا في الحقل الثاني، ثُمَّ عنوان الإصدار الرابع من بروتوكول الإنترنت.<ref name="RFC-69"/> وفي ما يأتي مثالٌ عن هذا العنوان: {{عنوان بروتوكول إنترنت في النسق|{{وسط|ffff:192.0.2.47::}}}} |
|||
| الأول2= B. |
|||
| تاريخ= سبتمبر 2004 |
|||
| مسار أرشيف = https://web.archive.org/web/20200507010545/https://tools.ietf.org/html/rfc3879 |
|||
| مسار= https://tools.ietf.org/html/rfc3879 |
|||
| عنوان= RFC 3879, Deprecating Site Local Addresses |
|||
| لغة= en |
|||
| doi = 10.17487/RFC3879 |
|||
|تاريخ أرشيف=2020-05-07}}</ref> طُوِّر في الأصل ليَخدُم غرض العنونة داخل موقع ما دون الحاجة لبادئات عالمية. حُجر له الفضاء {{عنوان بروتوكول إنترنت في النسق|fec::/10}}،<ref name="Book-15"/> كانت بنية هذه العناوين مكونة من ثلاثة حقول: الحقل الأول هو معرف فضاء العناوين المحلية في الموقع، وطوله 10 بتات وقيمته <sub>2</sub>(1111111011)، أما الحقل الثاني فهو مُعرِّف الشبكة الجزئية، ويضبطه مشرفو الموقع حسب الحاجة، وأما الحقل الثالث فهو مُعرِّف المضيف ويبلغ طوله 64 بتاً.<ref name="RFC-69"/> وفيما يأتي مثالٌ عن هذا العنوان: {{عنوان بروتوكول إنترنت في النسق|{{وسط|fec0::1234:5678:9abc}}}} |
|||
* ''' عناوين البث فريد الوجهة التي تتضمن عناوين من الإصدار الرابع''': هناك عنوانان من عناوين البث فريد الوجهة في الإصدار السادس يحملان في البتات الاثنين والثلاثين ذات الأهمية الدنيا عناوين من الإصدار الرابع من بروتوكول الإنترنت وهما: |
|||
:* '''عناوين البث فريدة الوجهة المُتوافِقة مع الإصدار الرابع''' {{إنج|IPv4-Compatible Unicast Address}}: عُرِّفت هذه العناوين في الأصل لتساهم في دعم عملية الانتقال من استعمال الإصدار الرابع إلى الإصدار السادس من بروتوكول الإنترنت. يتكون هذا العنوان بدءاً من الخانة الأكثر أهمية من 80 صفراً يليها عنوان الإصدار الرابع من بروتوكول الإنترنت الذي يلزم أن يكون فريداً عالمياً.<ref name="RFC-68"/> |
|||
:: تُستخدم الطريقة العجينة لتمثيل هذه العناوين. أبطلت طريقة الانتقال التي تستعمل هذه العناوين، ولذلك لم تعد هذه العناوين قيد الاستخدام.<ref name="RFC-68"/> وفيما يأتي مثالٌ عن هذا العنوان: {{عنوان بروتوكول إنترنت في النسق|{{وسط|200.100.10.1::}}}} |
|||
:* '''عناوين البث فريدة الوجهة المُقترنة مع الإصدار الرابع''' {{إنج| IPv4-Mapped Unicast Address}} وتستعمل لحمل عنوان الإصدار الرابع من بروتوكول الإنترنت الذي تستضيفه العقدة التي تدعم الإصدار السادس أيضاً.<ref name="RFC-68"/> وصفت طريقة استعمال هذا العنوان في وثيقة طلب التعليقات RFC 4038،<ref name="RFC-75">{{استشهاد ويب |
|||
| الأخير= Shin |
|||
| الأول= M-K. |
|||
| الأخير2= Hong |
|||
| الأول2= Y-G. |
|||
| الأخير3= Hagino |
|||
| الأول3= J. |
|||
| الأخير4= Savola |
|||
| الأول4= P. |
|||
| الأخير5= Castro |
|||
| الأول5= E. M. |
|||
| تاريخ= مارس 2004 |
|||
| مسار أرشيف = https://web.archive.org/web/20200414175806/https://tools.ietf.org/html/rfc4038 |
|||
| مسار= https://tools.ietf.org/html/rfc4038 |
|||
| عنوان= RFC 4038, Application Aspects of IPv6 Transition |
|||
| لغة= en |
|||
| doi = 10.17487/RFC4038 |
|||
|تاريخ أرشيف=2020-04-14}}</ref> وهو يتكون من ثلاث حقول بدءاً من الخانة الأكثر أهمية هي 80 صفراً متتالياً في الحقل الأول، يليها 16 واحداً متتالياً في الحقل الثاني، ثُمَّ عنوان الإصدار الرابع من بروتوكول الإنترنت.<ref name="RFC-69"/> وفيما يأتي مثالٌ عن هذا العنوان: {{عنوان بروتوكول إنترنت في النسق|{{وسط|ffff:192.0.2.47::}}}} |
|||
<gallery> |
<gallery> |
||
سطر 631: | سطر 361: | ||
===== عناوين البث نحو الأقرب ===== |
===== عناوين البث نحو الأقرب ===== |
||
عنوان البث نحو الأقرب في الإصدار السادس من بروتوكول الإنترنت {{إنج|IPv6 anycast address}} هو عنوان [[بث فريد|بث فريد الوجهة]] يُمنح لأكثر من [[منفذ (عتاد)|منفذ]] في الوقت عينه، |
عنوان البث نحو الأقرب في الإصدار السادس من بروتوكول الإنترنت {{إنج|IPv6 anycast address}} هو عنوان [[بث فريد|بث فريد الوجهة]] يُمنح لأكثر من [[منفذ (عتاد)|منفذ]] في الوقت عينه، وغالبًا ما تكون في هذه المنافذ في عقد متمايزة. إذا أُرسلت رزمة بيانات ما إلى عنوان بث نحو الأقرب، فإنها تُرسل إلى أقرب{{للهامش|5}} عقدة تستضيف ذلك العنوان. تُحصص عناوين البث نحو الأقرب من فضاء البث فريد الوجهة، من غير أي قيود إضافية، لذلك لا يمكن تمييز عناوين البث نحو الأقرب عن عناوين البث فريد الوجهة رياضيًّا. بعبارة أخرى، إذا مُنح عنوان بث فريد الوجهة إلى أكثر من منفذ في الوقت عينه فإنَّه يًصبح عنوان بثٍّ نحو الأقرب، ويجب تهيئة العقد بشكل صريح لتكون على دراية بذلك.<ref name="RFC-73">{{استشهاد مختصر|RFC 4291|ص=12|لغة=en}}</ref> |
||
يتكون عنوان البث نحو الأقرب من قسمين، يمُثل الأول بادئة الشبكة الجزئية، وهي مُعرِّف رقمي طوله n بت، يُحدد |
يتكون عنوان البث نحو الأقرب من قسمين، يمُثل الأول بادئة الشبكة الجزئية، وهي مُعرِّف رقمي طوله n بت، يُحدد جزءًا من الطوبولوجيا حيث توجد جميع العقد التي تستضيف عناوين بثٍ نحو الأقرب، أما القسم الآخر من العنوان فهو ذو قيمة صفرية.<ref name="RFC-73"/> |
||
يَلزَم أن تميير [[موجه (شبكات)|المُوجِّهات]] عنوان البث نحو الأقرب ببند فريد في [[جدول توجيه|جداول التوجيه]] ضمن جزء الطوبولوجيا الذي توجد فيه العناوين، ولكن خارج هذا الجزء، يمكن تجميع العنوان مع مسارات أخرى ولا داعٍ لتمييزه ببند فريد. توجد حالة خاصة يلزم أن يكون فيه بند عنوان البث نحو الأقرب فريدًا على مستوى الإنترنت كلها ولا يجوز تجميع هذا البند مع أي بند آخر، وتحصل هذه الحالة عند استعمال بادئة غير مُحدَدة طوبولوجيًّا {{إنج|null prefix}}، أي أنها يمكن أن تمنح للمنافذ في أي موقع في الإنترنت.<ref name="RFC-74">{{استشهاد مختصر|RFC 4291|ص=13|لغة=en}}</ref> |
|||
===== عناوين البث المجموعاتي ===== |
===== عناوين البث المجموعاتي ===== |
||
{{أيضا|بث مجموعاتي}} |
{{أيضا|بث مجموعاتي}} |
||
[[ملف:IPv6 multicast address stracture-ar.svg|تصغير|300بك|بنية عنوان البث المجموعاتي.]] |
[[ملف:IPv6 multicast address stracture-ar.svg|تصغير|300بك|بنية عنوان البث المجموعاتي.]] |
||
عنوان [[بث متعدد|البث المجموعاتي]] هو مُعرِّف رقمي يُميِّز مَجموعة محددة من [[منفذ (عتاد)|المنافذ]] التي تستضيفه. إن إرسال أي [[رزمة بيانات]] إلى عنوان بث مجموعاتي ما سيؤدي إلى [[توجيه (شبكات)|توجيهها]] إلى جميع أعضاء المجموعة المميزة بذلك العنوان.<ref name="Book-17">{{استشهاد |
عنوان [[بث متعدد الوجهات|البث المجموعاتي]] هو مُعرِّف رقمي يُميِّز مَجموعة محددة من [[منفذ (عتاد)|المنافذ]] التي تستضيفه. إن إرسال أي [[رزمة بيانات]] إلى عنوان بث مجموعاتي ما سيؤدي إلى [[توجيه (شبكات)|توجيهها]] إلى جميع أعضاء المجموعة المميزة بذلك العنوان.<ref name="Book-17">{{استشهاد مختصر|1=Dyson|2=1999|ص=242|لغة=en}}</ref> يتكون عنوان البث المجموعاتي من أربعة حقول هي وفقًا لترتيب ورودها من الخانة الأعلى أهمية:<ref name="RFC-74" /> |
||
* '''حقل بادئة البث المجموعاتي''': طوله 8 [[بت]]، ويحتوي القيمة <sub>2</sub>(11111111) أو <sub>16</sub>(FF)، وهي تميز عناوين فضاء البث المجموعاتي جميعها. |
|||
|مؤلف1= Peter Dyson |
|||
* '''حقل الأعلام''': طوله 4 بت، تُثبَّت قيمة البت الأعلى أهمية فيه إلى القيمة 0، وأما البتات الثلاثة اللاحقة في وفقًا لترتيب ورودها من الخانة الأعلى أهمية: |
|||
|مؤلف2= Kevin Shafer |
|||
:: علم الالتقاء: ويحدد فيما إذا كان العنوان يتضمن عنوان نقطة الالتقاء أم لا، فهو كذلك إذا كان واحديًّا، أما إذا كان صفريًّا فهو بخلاف ذلك.<ref name="RFC-77">{{استشهاد مختصر|RFC 3956|ص=5|لغة=en}}</ref> |
|||
|عنوان= Dictionary of Networking |
|||
:: علم البادئة: ويحدد فيما إذا كان منح العنوان قد جرى على أساس بادئة الشبكة فريدة الوجهة حيث سيُستضاف العنوان، فإذا كان العلم واحديًّا فإن العنوان قد منح على أساس البادئة وإلا فإنه لم يُمنح على ذلك الأساس.<ref name="RFC-78">{{استشهاد مختصر|RFC 3306|ص=3|لغة=en}}</ref> |
|||
| مسار = https://archive.org/details/dictionaryofnetworking |
|||
:: علم الديمومة: وإذا كان صفريًّا فإن العنوان ممنوح بشكل دائم من قبل أيانا ومعروفٌ في الإنترنت كاملةً، أما إذا كانت قيمته واحدية، فالعنوان ليس دائمًا ويكون ذا معنى في مجال مُحدد بحقل المجال.<ref name="RFC-74" /> |
|||
|طبعة= الثالثة |
|||
* '''حقل المجال''': طوله 4 بت، ويضم رمزًا يحدد المجال الطوبولوجي الذي تمتد عليه المجموعة كما في الجدول التالي:<ref name="RFC-80">{{استشهاد مختصر|RFC 7346|ص=3|لغة=en}}</ref> |
|||
|سنة=1999 |
|||
|ناشر= SYBEX Inc. |
|||
| صفحة = 1999 |
|||
|الرقم المعياري= 0782124615 |
|||
|لغة= en |
|||
| مسار أرشيف = https://web.archive.org/web/20200528153422/https://archive.org/details/dictionaryofnetworking | تاريخ أرشيف = 28 مايو 2020 }}</ref> يتكون عنوان البث المجموعاتي من أربعة حقول هي وفقاً لترتيب ورودها من الخانة الأعلى أهمية:<ref name="RFC-74" /> |
|||
* '''حقل بادئة البث المجموعاتي''': طوله 8 [[بت]]، ويحتوي على القيمة <sub>2</sub>(11111111) أو <sub>16</sub>(FF)، وهي تميز عناوين فضاء البث المجموعاتي جميعها. |
|||
* '''حقل الأعلام''': طوله 4 بت، تُثبَّت قيمة البت الأعلى أهمية فيه إلى القيمة 0، وأما البتات الثلاثة اللاحقة في وفقاً فقاً لترتيب ورودها من الخانة الأعلى أهمية: |
|||
:: علم الالتقاء: ويحدد فيما إذا كان العنوان يتضمن عنوان نقطة الالتقاء أم لا، فهو كذلك إذا كان واحدياً، أما إذا كان صفرياً فهو بخلاف ذلك.<ref name="RFC-77">{{استشهاد ويب |
|||
| الأخير= Savola |
|||
| الأول= P. |
|||
| الأخير2= Haberman |
|||
| الأول2= B. |
|||
| تاريخ= نوفمبر 2004 |
|||
| مسار أرشيف = https://web.archive.org/web/20200124160152/https://tools.ietf.org/html/rfc3956 |
|||
| مسار= https://tools.ietf.org/html/rfc3956 |
|||
| عنوان= RFC 3956, Application Aspects of IPv6 Transition |
|||
| لغة= en |
|||
|صفحة = 5 |
|||
| doi = 10.17487/RFC3956 |
|||
|تاريخ أرشيف=2020-01-24| تاريخ الوصول = 25 مايو 2020 |
|||
}}</ref> |
|||
:: علم البادئة: ويحدد فيما إذا كان منح العنوان قد جرى على أساس بادئة الشبكة فريدة الوجهة حيث سيُستضاف العنوان، فإذا كان العلم واحدياً فإن العنوان قد منح على أساس البادئة وإلا فإنه لم يُمنح على ذلك الأساس.<ref name="RFC-78">RFC 3306, P.3</ref> |
|||
:: علم الديمومة: وإذا كان صفرياً فإن العنوان ممنوح بشكل دائم من قبل أيانا ومعروفٌ في شبكة الإنترنت كاملةً، أما إذا كانت قيمته واحدية، فالعنوان ليس دائماً ويكون ذا معنى في مجال مُحدد بحقل المجال.<ref name="RFC-74" /> |
|||
* '''حقل المجال''': طوله 4 بت، ويضم رمزاً يحدد المجال الطوبولوجي الذي تمتد عليه المجموعة كما في الجدول التالي:<ref name="RFC-80">{{استشهاد ويب |
|||
| الأخير= Droms |
|||
| الأول= R. |
|||
| تاريخ= أغسطس 2014 |
|||
| مسار أرشيف = https://web.archive.org/web/20200124164314/https://tools.ietf.org/html/rfc7346 |
|||
| مسار= https://tools.ietf.org/html/rfc7346 |
|||
| عنوان= RFC 7346, IPv6 Multicast Address Scopes |
|||
| لغة= en |
|||
| doi = 10.17487/RFC7346 |
|||
|تاريخ أرشيف=2020-01-24| صفحة = 3 |
|||
| تاريخ الوصول = 25 مايو 2020 |
|||
|ISSN = 2070-1721 |
|||
}}</ref> |
|||
{| class="wikitable" |
{| class="wikitable" |
||
|- |
|- |
||
سطر 689: | سطر 383: | ||
| 0000 || محجوز|| - |
| 0000 || محجوز|| - |
||
|- |
|- |
||
| 0001 || مجال المنفذ|| يشمل هذا المجال [[منفذ (عتاد)| |
| 0001 || مجال المنفذ|| يشمل هذا المجال [[منفذ (عتاد)|منفذًا]] واحدًا في عقدة واحدة، ويستعمل هذا المجال في تطبيقات الحلقة العكسية. |
||
|- |
|- |
||
| 0010 || مجال الوصلة المحلية || يمتد المجال ليغطي [[شبكة محلية|الشبكة المحلية]] بشكلٍ متوافق مع شبكة عناوين [[بث فريد|البث فريد الوجهة]] المُستخدَمة |
| 0010 || مجال الوصلة المحلية || يمتد المجال ليغطي [[شبكة محلية|الشبكة المحلية]] بشكلٍ متوافق مع شبكة عناوين [[بث فريد|البث فريد الوجهة]] المُستخدَمة محليًّا. |
||
|- |
|- |
||
| 0011 || محجوز|| - |
| 0011 || محجوز|| - |
||
|- |
|- |
||
| 0100 || مجال الإشراف المحلي || يمتد المجال على جزء من الشبكة يقوم مشرفوها بتحديده، وهو أصغر مجال يمكن تحديده |
| 0100 || مجال الإشراف المحلي || يمتد المجال على جزء من الشبكة يقوم مشرفوها بتحديده، وهو أصغر مجال يمكن تحديده إشرافيًّا. |
||
|- |
|- |
||
| 0101 || مجال الموقع المحلي || يمتد المجال ليغطي |
| 0101 || مجال الموقع المحلي || يمتد المجال ليغطي موقعًا محليًّا واحدًا، قد يشمل عدة شبكات محلية، ولكنَّها تعود لمنظمة واحدة. |
||
|- |
|- |
||
| |
| 0100 || مجال المنظمة المحلي || يمتد المجال على عدة مواقع محلية لمنظمة واحدة. |
||
|- |
|- |
||
| |
| 1110 || المجال العالمي || يشمل المجال [[إنترنت|الإنترنت]] كاملة. |
||
|- |
|- |
||
| 1111 || محجوز|| - |
| 1111 || محجوز|| - |
||
|} |
|} |
||
:تكون قيم المجال غير المحجوزة وغير المُخصصة لمجال معين متاحة للاستخدام من قبل مشرفي الشبكة المحلية لتعريف مجالات فرعية تلائم أغراضهم الخاصة.<ref name="RFC-81">RFC 4291 |
: تكون قيم المجال غير المحجوزة وغير المُخصصة لمجال معين متاحة للاستخدام من قبل مشرفي الشبكة المحلية لتعريف مجالات فرعية تلائم أغراضهم الخاصة.<ref name="RFC-81">{{استشهاد مختصر|RFC 4291|ص=14|لغة=en}}</ref> |
||
* '''حقل مُعرف المجموعة'''، وطوله 112 بت، ويضم مُعرفًا رقميًّا يميز المجموعة ضمن المجال المُحدد بحقل المجال. توجد بنى عناوين بث مجموعاتي أكثر تخصصًا، ومنها مثلًا ما تُعرِّفه الوثيقة RFC 3306،<ref name="RFC-79">{{استشهاد مختصر|RFC 3306|ص=1|لغة=en}}</ref> وفيه يُقسم مُعرف المجموعة إلى ثلاثة أربعة حقول تتضمن مُعرِّفًا للمجموعة بطول 32 بت فقط، وحقلًا لبادئة شبكة البث فريد الوجهة الذي يُمنح العنوان على أساسها. وتصف الوثيقة RFC 7371 بنى عناوين البث المجموعاتي في الإصدار السادس وحالاتها المُختلفة ومعاني كلٍ منها.<ref name="RFC-82">{{استشهاد مختصر|RFC 7371|ص=1|لغة=en}}</ref> |
|||
* '''حقل مُعرف المجموعة'''، وطوله 112 بت، ويضم مُعرفاً رقمياً يميز المجموعة ضمن المجال المُحدد بحقل المجال. |
|||
هناك بنى عناوين بث مجموعاتي أكثر تخصصاً، ومنها مثلاً ما تُعرِّفه الوثيقة RFC 3306،<ref name="RFC-79">RFC 3306, P.1</ref> وفيه يُقسم مُعرف المجموعة إلى ثلاثة أربعة حقول تتضمن مُعرِّفاً للمجموعة بطول 32 بت فقط، وحقلاً لبادئة شبكة البث فريد الوجهة الذي يُمنح العنوان على أساسها. وتصف الوثيقة RFC 7371 بنى عناوين البث المجموعاتي في الإصدار السادس وحالاتها المُختلفة ومعاني كلٍ منها.<ref name="RFC-82">{{استشهاد ويب |
|||
| الأخير= Boucadair |
|||
| الأول= M. |
|||
| الأخير2= Venaas |
|||
| الأول2= S. |
|||
| تاريخ= سبتمبر 2014 |
|||
| مسار أرشيف = https://web.archive.org/web/20200124160201/https://tools.ietf.org/html/rfc7371 |
|||
| مسار= https://tools.ietf.org/html/rfc7371 |
|||
| عنوان= RFC 7371, Updates to the IPv6 Multicast Addressing Architecture |
|||
| لغة= en |
|||
| doi = 10.17487/RFC7371 |
|||
|تاريخ أرشيف=2020-01-24| تاريخ الوصول = 25 مايو 2020 |
|||
|ISSN = 2070-1721 |
|||
}}</ref> |
|||
==== أفضية محجوزة ==== |
==== أفضية محجوزة ==== |
||
توجد أفضية عناوين محجوزة مخصصَّة لبروتوكولات محددة أو لاستعمالات خاصة، ولا يجوز استعمال عناوين من هذه الأفضية من أجل عنونة المُضيفين في الإنترنت. تشرف هيئة أرقام الإِنترنت المُخصَّصة على حفظ وإدارة هذه الأفضية.<ref name="RFC-83">{{استشهاد مختصر|RFC 6890|ص=14-20|لغة=en}}</ref> |
|||
{{استشهاد ويب |
|||
| الأخير= Cotton |
|||
| الأول= M. |
|||
| الأخير2= Vegoda |
|||
| الأول2= L. |
|||
| الأخير3= Bonica, Ed. |
|||
| الأول3= R. |
|||
| الأخير4= Haberman |
|||
| الأول4= B. |
|||
| تاريخ= أبريل 2013 |
|||
| مسار أرشيف = https://web.archive.org/web/20200216072556/https://tools.ietf.org/html/rfc6890 |
|||
| مسار= https://tools.ietf.org/html/rfc6890 |
|||
| عنوان= RFC 6890, Special-Purpose IP Address Registries |
|||
| موقع=The Internet Society |
|||
| صفحة = 14-20 |
|||
| لغة= en |
|||
| doi = 10.17487/RFC6890 |
|||
| ISSN = 2070-1721 |
|||
|تاريخ أرشيف=2020-02-16}} |
|||
</ref> |
|||
===== أفضية البث فريد الوجهة والبث نحو الأقرب ===== |
===== أفضية البث فريد الوجهة والبث نحو الأقرب ===== |
||
{{أيضا|أفضية بروتوكول الإنترنت المحجوزة}} |
|||
<div class="reflist4" style="height: 250px; overflow: auto; padding: 3px" > |
|||
<section begin=الأفضية-المحجوز-في-البروتوكول-السادس/><!-- هذا الجدول مضمن في صفحات أخرى مثل [[أفضية بروتوكول الإنترنت المحجوزة]]. الرجاء عدم إزالة هذا القسم --> |
|||
<div class="reflist4" style="overflow: auto; padding: 3px" > |
|||
{| class="wikitable" |
{| class="wikitable" |
||
|+ جدول بأفضية العناوين الجزئية المحجوزة من فضاء عناوين الإصدار السادس من بروتوكول الإنترنت<ref name="Web-6">{{استشهاد ويب |
|+ جدول بأفضية العناوين الجزئية المحجوزة من فضاء عناوين الإصدار السادس من بروتوكول الإنترنت<ref name="Web-6" group="Web">{{استشهاد ويب |
||
| مسار أرشيف = https://web.archive.org/web/20200102182841/https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml |
| مسار أرشيف = https://web.archive.org/web/20200102182841/https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml |
||
| تاريخ أرشيف = 2 يناير 2020 |
| تاريخ أرشيف = 2 يناير 2020 |
||
سطر 762: | سطر 425: | ||
| {{عنوان بروتوكول إنترنت في النسق|1/128::}} || فبراير 2006 || عنوان الحلقة العكسية || <ref name="RFC-67"/> |
| {{عنوان بروتوكول إنترنت في النسق|1/128::}} || فبراير 2006 || عنوان الحلقة العكسية || <ref name="RFC-67"/> |
||
|- |
|- |
||
| {{عنوان بروتوكول إنترنت في النسق|ff9b::/96}}|| |
| {{عنوان بروتوكول إنترنت في النسق|ff9b::/96}}|| أكتوبر 2010 || مخصص لمترجمات العناوين بين الإصدارين الرابع والسادس || <ref name="RFC-85">{{استشهاد مختصر|RFC 6052|ص=5|لغة=en}}</ref> |
||
| الأخير= Bao |
|||
| الأول= C. |
|||
| الأخير2= Huitema |
|||
| الأول2= C. |
|||
| الأخير3= Bagnulo |
|||
| الأول3= M. |
|||
| الأخير4= Boucadair |
|||
| الأول4= M. |
|||
| الأخير5= Li |
|||
| الأول5= X. |
|||
| تاريخ=أكتوبر 2010 |
|||
| مسار أرشيف = https://web.archive.org/web/20200510171848/https://tools.ietf.org/html/rfc6052 |
|||
| مسار= https://tools.ietf.org/html/rfc6052 |
|||
| عنوان= RFC 6052, IPv6 Addressing of IPv4/IPv6 Translators |
|||
| موقع=The Internet Society |
|||
| صفحة = 5 |
|||
| لغة= en |
|||
| doi = 10.17487/RFC6052 |
|||
| ISSN = 2070-1721 |
|||
|تاريخ أرشيف=2020-05-10}}</ref> |
|||
|- |
|- |
||
| {{عنوان بروتوكول إنترنت في النسق|ffff:0:0/96::}} || فبراير 2006 || فضاء العناوين المقترنة مع الإصدار الرابع || <ref name="RFC-67"/> |
| {{عنوان بروتوكول إنترنت في النسق|ffff:0:0/96::}} || فبراير 2006 || فضاء العناوين المقترنة مع الإصدار الرابع || <ref name="RFC-67"/> |
||
|- |
|- |
||
| {{عنوان بروتوكول إنترنت في النسق|64/::100}} || يونيو 2012 || بادئة الاستبعاد {{إنج|Discard Prefix}}، |
| {{عنوان بروتوكول إنترنت في النسق|64/::100}} || يونيو 2012 || بادئة الاستبعاد {{إنج|Discard Prefix}}، وهي بادئة تستعمل في عملية التوجيه والترشيح للتخلص من رزم البيانات|| <ref name="RFC-86">{{استشهاد مختصر|RFC 6666|ص=4|لغة=en}}</ref> |
||
{{استشهاد ويب |
|||
| الأخير= Hilliard |
|||
| الأول= N. |
|||
| الأخير2= Freedman |
|||
| الأول2= D. |
|||
| تاريخ=أغسطس 2012 |
|||
| مسار أرشيف = https://web.archive.org/web/20200125211805/https://tools.ietf.org/html/rfc6666 |
|||
| مسار= https://tools.ietf.org/html/rfc6666 |
|||
| عنوان= RFC 6666, A Discard Prefix for IPv6 |
|||
| موقع=The Internet Society |
|||
| صفحة = 4 |
|||
| لغة= en |
|||
| doi = 10.17487/RFC6666 |
|||
| ISSN = 2070-1721 |
|||
|تاريخ أرشيف=2020-01-25}} |
|||
</ref> |
|||
|- |
|- |
||
| {{عنوان بروتوكول إنترنت في النسق|23/::2001}} || سبتمبر 2000 || مخصص لعملية تطوير إرشادات لمنح أفضية الإصدار السادس من بروتوكول الإنترنت || <ref name="RFC-87"> |
| {{عنوان بروتوكول إنترنت في النسق|23/::2001}} || سبتمبر 2000 || مخصص لعملية تطوير إرشادات لمنح أفضية الإصدار السادس من بروتوكول الإنترنت || <ref name="RFC-87">{{استشهاد مختصر|RFC 2928|ص=1|لغة=en}}</ref> |
||
{{استشهاد ويب |
|||
| الأخير= Hinden |
|||
| الأول= R. |
|||
| الأخير2= Deering |
|||
| الأول2= S. |
|||
| الأخير3= Fink |
|||
| الأول3= R. |
|||
| الأخير4= Hain |
|||
| الأول4= T. |
|||
| تاريخ=سبتمبر 2000 |
|||
| مسار أرشيف = https://web.archive.org/web/20200127003500/https://tools.ietf.org/html/rfc2928 |
|||
| مسار= https://tools.ietf.org/html/rfc2928 |
|||
| عنوان= RFC 2928, Initial IPv6 Sub-TLA ID Assignments |
|||
| موقع=The Internet Society |
|||
| صفحة = 1 |
|||
| لغة= en |
|||
| doi = 10.17487/RFC2928 |
|||
| ISSN = |
|||
|تاريخ أرشيف=2020-01-27}}</ref> |
|||
|- |
|- |
||
| {{عنوان بروتوكول إنترنت في النسق|32/::2001}} || فبراير 2006 || مخصص لدعم تقنية [[نفق تيريدو|تيريدو]] للانتقال من الإصدار الرابع نحو الإصدار السادس من بروتوكول الإنترنت || <ref name="RFC-88"> |
| {{عنوان بروتوكول إنترنت في النسق|32/::2001}} || فبراير 2006 || مخصص لدعم تقنية [[نفق تيريدو|تيريدو]] للانتقال من الإصدار الرابع نحو الإصدار السادس من بروتوكول الإنترنت || <ref name="RFC-88">{{استشهاد مختصر|RFC 4380|ص=4|لغة=en}}</ref> |
||
{{استشهاد ويب |
|||
| الأخير= Huitema |
|||
| الأول= C. |
|||
| تاريخ=فبراير 2006 |
|||
| مسار أرشيف = https://web.archive.org/web/20200511230249/https://tools.ietf.org/html/rfc4380 |
|||
| مسار= https://tools.ietf.org/html/rfc4380 |
|||
| عنوان= RFC 4380, Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs) |
|||
| موقع=The Internet Society |
|||
| صفحة = 4 |
|||
| لغة= en |
|||
| doi = 10.17487/RFC4380 |
|||
| ISSN = |
|||
|تاريخ أرشيف=2020-05-11}} |
|||
</ref> |
|||
|- |
|- |
||
| {{عنوان بروتوكول إنترنت في النسق|1/48::2001:1}} || أكتوبر 2015 || عنوان مُخصص للبث نحو الأقرب {{وإو|بروتوكول التحكم بالمنافذ|Port Control Protocol|en|لبروتوكول التحكم بالمنافذ}} || <ref name="RFC-89"> |
| {{عنوان بروتوكول إنترنت في النسق|1/48::2001:1}} || أكتوبر 2015 || عنوان مُخصص للبث نحو الأقرب {{وإو|بروتوكول التحكم بالمنافذ|Port Control Protocol|en|لبروتوكول التحكم بالمنافذ}} || <ref name="RFC-89"> |
||
{{استشهاد |
{{استشهاد مختصر|RFC 7723|ص=5|لغة=en}}</ref> |
||
| الأخير= Kiesel |
|||
| الأول= S. |
|||
| الأخير2= Penno |
|||
| الأول2= R. |
|||
| تاريخ=يناير 2016 |
|||
| مسار أرشيف = https://web.archive.org/web/20200507123527/https://tools.ietf.org/html/rfc7723 |
|||
| مسار= https://tools.ietf.org/html/rfc7723 |
|||
| عنوان= RFC 7723, Port Control Protocol (PCP) Anycast Addresses |
|||
| موقع=The Internet Society |
|||
| صفحة = 5 |
|||
| لغة= en |
|||
| doi = 10.17487/RFC7723 |
|||
| ISSN = 2070-1721 |
|||
|تاريخ أرشيف=2020-05-07}} |
|||
</ref> |
|||
|- |
|- |
||
| {{عنوان بروتوكول إنترنت في النسق|2/48::2001:1}} || فبراير 2017 || عنوان مُخصص للبث نحو الأقرب {{وإو|بروتوكول تخطي الترجمة باستعمال المرحلات|Traversal Using Relays around NAT|en|بروتوكول تخطي الترجمة باستعمال المُرحلات}} {{اختصار مخفي| TURN|Traversal Using Relays around NAT}} || <ref name="RFC-90"> |
| {{عنوان بروتوكول إنترنت في النسق|2/48::2001:1}} || فبراير 2017 || عنوان مُخصص للبث نحو الأقرب {{وإو|بروتوكول تخطي الترجمة باستعمال المرحلات|Traversal Using Relays around NAT|en|بروتوكول تخطي الترجمة باستعمال المُرحلات}} {{اختصار مخفي| TURN|Traversal Using Relays around NAT}} || <ref name="RFC-90">{{استشهاد مختصر|RFC 8155|ص=9|لغة=en}}</ref> |
||
{{استشهاد ويب |
|||
| الأخير= Patil |
|||
| الأول= P. |
|||
| الأخير2= Reddy |
|||
| الأول2= T. |
|||
| الأخير3= Wing |
|||
| الأول3= D. |
|||
| تاريخ=أبريل 2017 |
|||
| مسار أرشيف = https://web.archive.org/web/20200416064547/https://tools.ietf.org/html/rfc8155 |
|||
| مسار= https://tools.ietf.org/html/rfc8155 |
|||
| عنوان= RFC 8155, Traversal Using Relays around NAT (TURN) Server Auto Discovery |
|||
| موقع=The Internet Society |
|||
| صفحة = 9 |
|||
| لغة= en |
|||
| doi = 10.17487/RFC8155 |
|||
| ISSN = 2070-1721 |
|||
|تاريخ أرشيف=2020-04-16}} |
|||
</ref> |
|||
|- |
|- |
||
| {{عنوان بروتوكول إنترنت في النسق|48/::2001:2}} || أبريل 2008 || فضاء مخصص لعملية [[مقارنة مرجعية|المقارنة المرجعية]] || <ref name="RFC-91">{{استشهاد |
| {{عنوان بروتوكول إنترنت في النسق|48/::2001:2}} || أبريل 2008 || فضاء مخصص لعملية [[مقارنة مرجعية|المقارنة المرجعية]] || <ref name="RFC-91">{{استشهاد مختصر|RFC 5180|ص=11|لغة=en}}</ref> |
||
| الأخير= Popoviciu |
|||
| الأول= C. |
|||
| الأخير2= Hamza |
|||
| الأول2= A. |
|||
| الأخير3= Van de Velde |
|||
| الأول3= G. |
|||
| الأخير4= Dugatkin |
|||
| الأول4= D. |
|||
| تاريخ=مايو 2008 |
|||
| مسار أرشيف = https://web.archive.org/web/20200311164400/https://tools.ietf.org/html/rfc5180 |
|||
| مسار= https://tools.ietf.org/html/rfc5180 |
|||
| عنوان= RFC 5180, IPv6 Benchmarking Methodology for Network Interconnect Devices |
|||
| موقع=The Internet Society |
|||
| صفحة = 11 |
|||
| لغة= en |
|||
| doi = 10.17487/RFC5180 |
|||
| ISSN = |
|||
|تاريخ أرشيف=2020-03-11}}</ref> |
|||
|- |
|- |
||
| {{عنوان بروتوكول إنترنت في النسق|32/::2001:3}} || ديسمبر 2014 || فضاء مخصص للإنشاء الآلي لأنفاق البث المجموعاتي |
| {{عنوان بروتوكول إنترنت في النسق|32/::2001:3}} || ديسمبر 2014 || فضاء مخصص للإنشاء الآلي لأنفاق البث المجموعاتي || <ref name="RFC-92">{{استشهاد مختصر|RFC 7450|ص=78|لغة=en}}</ref> |
||
| الأخير= Bumgardner |
|||
| الأول= G. |
|||
| تاريخ=فبراير 2015 |
|||
| مسار أرشيف = https://web.archive.org/web/20200416064532/https://tools.ietf.org/html/rfc7450 |
|||
| مسار= https://tools.ietf.org/html/rfc7450 |
|||
| عنوان= RFC 7450, Automatic Multicast Tunneling |
|||
| موقع=The Internet Society |
|||
| صفحة =78 |
|||
| لغة= en |
|||
| doi = 10.17487/RFC7450 |
|||
| ISSN = 2070-1721 |
|||
|تاريخ أرشيف=2020-04-16}}</ref> |
|||
|- |
|- |
||
| {{عنوان بروتوكول إنترنت في النسق|48/::2001:4:112}} || ديسمبر 2014 || فضاء مخصص لمشروع النظام المستقل رقم 112 {{إنج|AS112 project}} |
| {{عنوان بروتوكول إنترنت في النسق|48/::2001:4:112}} || ديسمبر 2014 || فضاء مخصص لمشروع النظام المستقل رقم 112 {{إنج|AS112 project}} || <ref name="RFC-93">{{استشهاد مختصر|RFC 7535|ص=7|لغة=en}}</ref> |
||
| الأخير= Abley |
|||
| الأول= J. |
|||
| الأخير2= Dickson |
|||
| الأول2= B. |
|||
| الأخير3= Kumari |
|||
| الأول3= W. |
|||
| الأخير3= Michaelson |
|||
| الأول3= G. |
|||
| تاريخ=مايو 2015 |
|||
| مسار أرشيف = https://web.archive.org/web/20200507123556/https://tools.ietf.org/html/rfc7535 |
|||
| مسار= https://tools.ietf.org/html/rfc7535 |
|||
| عنوان= RFC 7535, AS112 Redirection Using DNAME |
|||
| موقع=The Internet Society |
|||
| صفحة =4 |
|||
| لغة= en |
|||
| doi = 10.17487/RFC7535 |
|||
| ISSN = 2070-1721 |
|||
|تاريخ أرشيف=2020-05-07}}</ref> |
|||
|- |
|- |
||
| {{عنوان بروتوكول إنترنت في النسق|28/::2001:10}} || أبريل 2007{{للهامش|9}} || فضاء مخصص لبادئة معرفات التجزئة |
| {{عنوان بروتوكول إنترنت في النسق|28/::2001:10}} || أبريل 2007{{للهامش|9}} || فضاء مخصص لبادئة معرفات التجزئة [[علم التعمية|المُعمَّاة]] المتراكبة القابلة للتوجيه، المعروفة اختصارًا بالاسم الرمزي: أوركيد {{اختصار مخفي|ORCHID|Overlay Routable Cryptographic Hash Identifiers}}|| <ref name="RFC-94">{{استشهاد مختصر|RFC 4843|ص=5|لغة=en}}</ref> |
||
{{استشهاد ويب |
|||
| الأخير= Nikander |
|||
| الأول= P. |
|||
| الأخير2= Laganier |
|||
| الأول2= J. |
|||
| الأخير3= Dupont |
|||
| الأول3= F. |
|||
| تاريخ=أبريل 2007 |
|||
| مسار أرشيف = https://web.archive.org/web/20200125125249/https://tools.ietf.org/html/rfc4843 |
|||
| مسار= https://tools.ietf.org/html/rfc4843 |
|||
| عنوان= RFC 4843, An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID) |
|||
| موقع=The Internet Society |
|||
| صفحة = 5 |
|||
| لغة= en |
|||
| doi = 10.17487/RFC4843 |
|||
| ISSN = |
|||
|تاريخ أرشيف=2020-01-25}}</ref> |
|||
|- |
|- |
||
| {{عنوان بروتوكول إنترنت في النسق|28/::2001:20}} || يوليو 2014 || فضاء مخصص للإصدار الثاني لبادئة معرفات التجزئة |
| {{عنوان بروتوكول إنترنت في النسق|28/::2001:20}} || يوليو 2014 || فضاء مخصص للإصدار الثاني لبادئة معرفات التجزئة [[علم التعمية|المُعمَّاة]] المتراكبة القابلة للتوجيه، المعروفة اختصارًا بالاسم الرمزي: أوركيد 2|| <ref name="RFC-95">{{استشهاد مختصر|RFC 7343|ص=6|لغة=en}}</ref> |
||
| الأخير= Laganier |
|||
| الأول= J. |
|||
| الأخير2= Dupont |
|||
| الأول2= F. |
|||
| تاريخ=سبتمبر 2014 |
|||
| مسار أرشيف = https://web.archive.org/web/20200124215601/https://tools.ietf.org/html/rfc7343 |
|||
| مسار= https://tools.ietf.org/html/rfc7343 |
|||
| عنوان= RFC 7343, an IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) |
|||
| موقع=The Internet Society |
|||
| صفحة = 6 |
|||
| لغة= en |
|||
| doi = 10.17487/RFC7343 |
|||
| ISSN = 2070-1721 |
|||
|تاريخ أرشيف=2020-01-24}}</ref> |
|||
|- |
|- |
||
| {{عنوان بروتوكول إنترنت في النسق|2001:0db8::/32}} || يوليو 2004 || فضاء مخصص لعملية التوثيق || <ref name="RFC-96">{{استشهاد |
| {{عنوان بروتوكول إنترنت في النسق|2001:0db8::/32}} || يوليو 2004 || فضاء مخصص لعملية التوثيق || <ref name="RFC-96">{{استشهاد مختصر|RFC 3849|ص=1|لغة=en}}</ref> |
||
| الأخير= Huston |
|||
| الأول= G. |
|||
| الأخير2= Dickson |
|||
| الأول2= B. |
|||
| الأخير3= Lord |
|||
| الأول3= A. |
|||
| الأخير4= Smith |
|||
| الأول4= P. |
|||
| تاريخ=يوليو 2004 |
|||
| مسار أرشيف = https://web.archive.org/web/20200526230942/https://tools.ietf.org/html/rfc3849 |
|||
| مسار= https://tools.ietf.org/html/rfc3849 |
|||
| عنوان= RFC 3849, IPv6 Address Prefix Reserved for Documentation |
|||
| موقع=The Internet Society |
|||
| صفحة =1 |
|||
| لغة= en |
|||
| doi = 10.17487/RFC3849 |
|||
| ISSN = |
|||
|تاريخ أرشيف=2020-05-26}}</ref> |
|||
|- |
|- |
||
| {{عنوان بروتوكول إنترنت في النسق|16/::2002}} || فبراير 2001 || فضاء مخصص لدعم تقنية 6 إلى 4 {{إنج|6to4}} للانتقال من الإصدار السادس نحو الإصدار الرابع من بروتوكول الإنترنت ||<ref name="RFC-97">{{استشهاد |
| {{عنوان بروتوكول إنترنت في النسق|16/::2002}} || فبراير 2001 || فضاء مخصص لدعم تقنية 6 إلى 4 {{إنج|6to4}} للانتقال من الإصدار السادس نحو الإصدار الرابع من بروتوكول الإنترنت ||<ref name="RFC-97">{{استشهاد مختصر|RFC 3056|ص=5|لغة=en}}</ref> |
||
| الأخير= Carpenter |
|||
| الأول= B. |
|||
| الأخير2= Moore |
|||
| الأول2= K. |
|||
| تاريخ=فبراير 2001 |
|||
| مسار أرشيف = https://web.archive.org/web/20200512033342/https://tools.ietf.org/html/rfc3056 |
|||
| مسار= https://tools.ietf.org/html/rfc3056 |
|||
| عنوان= RFC 3056, Connection of IPv6 Domains via IPv4 Clouds |
|||
| موقع=The Internet Society |
|||
| صفحة =5 |
|||
| لغة= en |
|||
| doi = 10.17487/RFC3056 |
|||
| ISSN = |
|||
|تاريخ أرشيف=2020-05-12}}</ref> |
|||
|- |
|||
| {{عنوان بروتوكول إنترنت في النسق|2620:4f:8000::/48}} || مايو 2001 || فضاء مخصص لخدمة التفويض المباشر في مشروع النظام المستقل رقم 112 || <ref name="RFC-98">{{استشهاد ويب |
|||
| الأخير= Abley |
|||
| الأول= J. |
|||
| الأخير2= Sotomayor |
|||
| الأول2= W. |
|||
| تاريخ=مايو 2015 |
|||
| مسار أرشيف = https://web.archive.org/web/20200416064542/https://tools.ietf.org/html/rfc7534 |
|||
| مسار= https://tools.ietf.org/html/rfc7534 |
|||
| عنوان= RFC 7534, AS112 Nameserver Operations |
|||
| موقع=The Internet Society |
|||
| صفحة =6 |
|||
| لغة= en |
|||
| doi = 10.17487/RFC7534 |
|||
| ISSN = 2070-1721 |
|||
|تاريخ أرشيف=2020-04-16}}</ref> |
|||
|- |
|- |
||
| {{عنوان بروتوكول إنترنت في النسق|fc00::/7}} || أكتوبر 2005 || مخصص لفضاء عناوين البث فريد الوجهة الفريد المحلي || <ref name="RFC-99"> |
| {{عنوان بروتوكول إنترنت في النسق|fc00::/7}} || أكتوبر 2005 || مخصص لفضاء عناوين البث فريد الوجهة الفريد المحلي || <ref name="RFC-99">{{استشهاد مختصر|RFC 4293|ص=3|لغة=en}}</ref> |
||
|- |
|- |
||
| {{عنوان بروتوكول إنترنت في النسق|fe80::/10}} || أكتوبر 2005 || مخصص لفضاء عناوين البث فريد الوجهة في الوصلة المحلية |
| {{عنوان بروتوكول إنترنت في النسق|fe80::/10}} || أكتوبر 2005 || مخصص لفضاء عناوين البث فريد الوجهة في الوصلة المحلية || <ref name="RFC-69"/> |
||
|} |
|} |
||
</div> |
</div> |
||
<section end=الأفضية-المحجوز-في-البروتوكول-السادس/><!-- هذا الجدول مضمن في صفحات أخرى مثل [[أفضية بروتوكول الإنترنت المحجوزة]]. الرجاء عدم إزالة هذا القسم --> |
|||
===== فضاء البث المجموعاتي ===== |
===== فضاء البث المجموعاتي ===== |
||
تدير أيانا فضاء عناوين البث المجموعاتي في الإصدار السادس من بروتوكول الإنترنت، وهو الفضاء الذي يتحدد |
تدير أيانا فضاء عناوين البث المجموعاتي في الإصدار السادس من بروتوكول الإنترنت، وهو الفضاء الذي يتحدد بالبادئة ff00::/8.<ref name="Web-7" group="Web">{{استشهاد ويب |
||
| مسار أرشيف = https://web.archive.org/web/20200507123528/https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml |
| مسار أرشيف = https://web.archive.org/web/20200507123528/https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml |
||
| تاريخ أرشيف = 7 مايو |
| تاريخ أرشيف = 7 مايو 2020 |
||
| مسار= https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml |
| مسار= https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml |
||
| عنوان= IPv6 Multicast Address Space Registry |
| عنوان= IPv6 Multicast Address Space Registry |
||
| موقع= IANA |
| موقع= IANA |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 25 مايو 2020}}</ref> |
| تاريخ الوصول= 25 مايو 2020}}</ref> توجد مجموعة من العناوين المُعرَّفة المحجوزة التي لا يجب منحها لأي مجموعة في شبكات الإصدار السادس، وهي:<ref name="RFC-100">{{استشهاد مختصر|RFC 4291|ص=16-17|لغة=en}}</ref> |
||
* جميع العناوين ذات البنية {{عنوان بروتوكول إنترنت في النسق| |
* جميع العناوين ذات البنية {{عنوان بروتوكول إنترنت في النسق|ff0#:0:0:0:0:0:0:0}}، وعددها 16 عنوانًا، حيث # هي مرتبة [[نظام عد ستة عشري|ستة عشرية]] تأخذ أي قيمة من المجال {9 .. 1,2} أو{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: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}}. |
* عناوين مجموعات كل الموجهات في مجال المنفذ والمجال المحلي ومجال الموقع، وهذه العناوين هي على الترتيب: {{عنوان بروتوكول إنترنت في النسق|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}} من أجل مجموعة كل الموجهات التي تشغل [[بروتوكول التوجيه الداخلي المحسن بين البوابات]] وغير ذلك.<ref name="Web-7" group="Web"/> |
||
==== عناوين ملزمة ==== |
==== عناوين ملزمة ==== |
||
تميّز معايير الإصدار السادس من بروتوكول الإنترنت بين [[مضيف (حوسبة)|المُضيف]] و[[ |
تميّز معايير الإصدار السادس من بروتوكول الإنترنت بين [[مضيف (حوسبة)|المُضيف]] و[[موجه (شبكات)|المُوجِّه]]، فالموجه هو عقدة [[توجيه (شبكات)|تُوجِّه]] رزم بيانات لم تولدها للإصدار السادس من بروتوكول الإنترنت. أمَّا المُضيف فهو أي عقدة ما خلا الموجهات.<ref name="RFC-31"/> بناءً على ذلك، يلزم على كل مُضيف أن يكون قادرًا على تمييز العناوين التالية بصفتها معرفاتٍ ذاتية:<ref name="RFC-101">{{استشهاد مختصر|RFC 4291|ص=17|لغة=en}}</ref> |
||
* عنوان محلي في الوصلة من أجل كل [[منفذ (عتاد)|منفذ]] من منافذه. |
* عنوان محلي في الوصلة من أجل كل [[منفذ (عتاد)|منفذ]] من منافذه. |
||
* عنوان الحلقة العكسية. |
* عنوان الحلقة العكسية. |
||
* أي عناوين [[بث فريد|بث فريد الوجهة]] أو بث نحو الأقرب جرى تهيئته بها، سواء كانت التهيئة يدويةً أو آليةً. |
* أي عناوين [[بث فريد|بث فريد الوجهة]] أو بث نحو الأقرب جرى تهيئته بها، سواء كانت التهيئة يدويةً أو آليةً. |
||
* جميع عناوين [[بث متعدد|البث المجموعاتي]] المحجوزة للعقد. |
* جميع عناوين [[بث متعدد الوجهات|البث المجموعاتي]] المحجوزة للعقد. |
||
* عنوان البث |
* عنوان البث المجموعاتي الخاص بالتماس العقدة من أجل كل عنوان بث فريد الوجهة أو بث نحو الأقرب. |
||
* أي عناوين بث مجموعاتي تُمثل مجموعات انضم المُضيف إليها. |
* أي عناوين بث مجموعاتي تُمثل مجموعات انضم المُضيف إليها. |
||
أمَّا المُوجِّه، فيلزم أن يميز العناوين السابقة التي يميزها المضيف، |
أمَّا المُوجِّه، فيلزم أن يميز العناوين السابقة التي يميزها المضيف، وأيضًا العناوين التالية، بوصفها مُعرفات ذاتية:<ref name="RFC-101"/> |
||
* عناوين البث نحو الأقرب للشبكات [[تجزئة الشبكة|الجزئية]] على جميع المنافذ التي هُيِّئت لتعمل بوصفها منافذَ للمُوجه. |
* عناوين البث نحو الأقرب للشبكات [[تجزئة الشبكة|الجزئية]] على جميع المنافذ التي هُيِّئت لتعمل بوصفها منافذَ للمُوجه. |
||
* جميع عناوين البث نحو الأقرب التي جرت تهيئة |
* جميع عناوين البث نحو الأقرب التي جرت تهيئة المُوجِّه بها. |
||
* جميع عناوين البث المجموعاتي المحجوزة للمُوجِّهات.<ref name="Web-7"/> |
* جميع عناوين البث المجموعاتي المحجوزة للمُوجِّهات.<ref name="Web-7" group="Web"/> |
||
==== التهيئة الذاتية الآلية ==== |
==== التهيئة الذاتية الآلية ==== |
||
التهيئة الذاتية الآلية في الإصدار السادس من بروتوكول الإنترنت {{إنج|IPv6 Stateless Address Autoconfiguration}} هي آلية تحدد الخطوات التي يتخذها مضيفو الإصدار السادس من أجل تهيئة منافذهم |
التهيئة الذاتية الآلية في الإصدار السادس من بروتوكول الإنترنت أو التهيئة غير المركزية الآلية {{إنج|IPv6 Stateless Address Autoconfiguration}} هي آلية تحدد الخطوات التي يتخذها مضيفو الإصدار السادس من أجل تهيئة منافذهم ذاتيًّا بعناوين وصلة محلية أو عناوين عالمية باستعمال معرفات المنفذ المولدة محليًَّا ومعلومات البادئات التي يحصل المُضيف عليها من إعلانات الموجهات في الشبكة المحلية، وتشمل هذه الآلية أيضًا إجراءاتٍ مُحددة لاكتشاف الاستخدام المتعدد للعنوان لضمان فرادته على مستوى الوصلة المحلية. لا تتطلب التهيئة الذاتية أي إعداد يدوي في المضيفين، وإعداد بسيطًا، وقد لا يكون ضروريًّا، في الموجهات وهي لا تحتاج لوجود مُخدِّمات. يمكن للمضيف، في غياب الموجهات، أن يولد عنوانًا محليًّا في الوصلة ذاتيًّا دون أي تدخل خارجي.<ref name="RFC-102">{{استشهاد مختصر|RFC 4862|ص=3|لغة=en}}</ref> |
||
تحصل عملية التهيئة الذاتية الآلية في المنافذ التي تدعم الإصدار السادس من بروتوكول الإنترنت في أربع حالات هي: تشغيل المنفذ بعد إقلاع النظام، وإعادة تشغيل المنفذ بعد |
تحصل عملية التهيئة الذاتية الآلية في المنافذ التي تدعم الإصدار السادس من بروتوكول الإنترنت في أربع حالات هي: تشغيل المنفذ بعد إقلاع النظام، وإعادة تشغيل المنفذ بعد إخفاق سابق له، واتصال المنفذ مع شبكة ما للمرة الأولى، وإعادة تفعيل المنفذ بعد تعطيل سابق لأسباب إشرافية.<ref name="RFC-103">{{استشهاد مختصر|RFC 4862|ص=11-12|لغة=en}}</ref> تحصل عملية التوليد الذاتية الآلية لعنوان محلي في الوصلة باتباع الخطوات التالية:<ref name="RFC-104">{{استشهاد مختصر|RFC 4862|ص=12|لغة=en}}</ref> |
||
# تكون بادئة العنوان هي {{عنوان بروتوكول إنترنت في النسق|FE80::/10}}، وتحجز البتات العشرة الأعلى أهمية. |
# تكون بادئة العنوان هي {{عنوان بروتوكول إنترنت في النسق|FE80::/10}}، وتحجز البتات العشرة الأعلى أهمية. |
||
# |
# يُملأ سائر العنوان بالأصفار. |
||
# يحسب مُعرِّف المنفذ وليكن طوله N بت، وقد يحتوي |
# يحسب مُعرِّف المنفذ وليكن طوله N بت، وقد يحتوي عنوان مادي موجود في المنفذ نفسه، ويكون طوله 64 بت في الغالب. |
||
# |
# بدءًا من الخانة الأقل أهمية في العنوان يُستبدل N صفرًا في العنوان بمُعرف المنفذ. |
||
يمكن |
يمكن أيضًا أن تستخدم الآلية السابقة نفسها في تشكيل عناوين فريدة عالميًّا بشكل ذاتي وآلي. ولتحقيق ذلك، يلزم أن يحصل المُضيف على البادئة الفريدة عالميًّا باستعمال بروتوكول اكتشاف الجيران سواء عن طريق إرسال رسالة التماس للمُوجهات الموجودة في الشبكة المحلية أو انتظار رسائل الإعلان التي تُرسلها بشكل دوري. بعد ذلك، يستعمل المضيف البادئة التي حصل عليها في الخطوة الأولى من الخوارزمية السابقة بدلًا من بادئة فضاء العناوين المحلية في الوصلة {{عنوان بروتوكول إنترنت في النسق|FE80::/10}}، ثُمَّ يتابع تنفيذ بقية الخطوات كما وردت.<ref name="RFC-105">{{استشهاد مختصر|RFC 4862|ص=17-21|لغة=en}}</ref> |
||
في ما يخص مُعرفات المنافذ، فيمكن توليدها باستعمال العناوين المادية كما في آلية توليد المُعرّف الفريد المُوسّع ({{اختصار مخفي|EUI|Extended Unique Identifier}}) المطورة من قبل [[معهد مهندسي الكهرباء والإلكترونيات]]،<ref name="Web-8"/> أو تُولَّد بصورة مستقلة العناوين المادية باعتماد خوارزمية موصوفة في [[طلب تعليقات|وثيقة طلب التعليقات]] RFC 7217 وتكون المُعرفات الناتجة عنها آمنة ومستقرة وفريدة على المستويين المحلي والعالمي.<ref name="RFC-106">{{استشهاد مختصر|RFC 7217|ص=5|لغة=en}}</ref> |
|||
| الأخير= Gont |
|||
| الأول= F. |
|||
| تاريخ=أبريل 2014 |
|||
| مسار أرشيف = https://web.archive.org/web/20200208171804/https://tools.ietf.org/html/rfc7217 |
|||
| مسار= https://tools.ietf.org/html/rfc7217 |
|||
| عنوان= RFC 7217, A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) |
|||
| موقع=The Internet Society |
|||
| صفحة =5 |
|||
| لغة= en |
|||
| doi = 10.17487/RFC7217 |
|||
| ISSN = 2070-1721 |
|||
|تاريخ أرشيف=2020-02-08}}</ref> |
|||
==== إدارة فضاء العناوين: التحصيص والمنح ==== |
==== إدارة فضاء العناوين: التحصيص والمنح ==== |
||
سطر 1٬086: | سطر 509: | ||
[[ملف:IPv6 Prefix Assignment Example-ar.svg|تصغير|300بك|مثال عن مستويات التحصيص في الإصدار السادس من بروتوكول الإنترنت.]] |
[[ملف:IPv6 Prefix Assignment Example-ar.svg|تصغير|300بك|مثال عن مستويات التحصيص في الإصدار السادس من بروتوكول الإنترنت.]] |
||
بشكل مشابه [[بروتوكول الإنترنت (الإصدار الرابع)|للإصدار الرابع من بروتوكول الإنترنت]]، تُشرف [[آيكان|شركة الإنترنت للأرقام والأسماء الممنوحة]] المعروفة |
بشكل مشابه [[بروتوكول الإنترنت (الإصدار الرابع)|للإصدار الرابع من بروتوكول الإنترنت]]، تُشرف [[آيكان|شركة الإنترنت للأرقام والأسماء الممنوحة]] المعروفة اختصارًا بالاسم آيكان، عبر [[أيانا|هيئة أرقام الإنترنت المُخصصة]] على تحصيص فضاء عناوين الإصدار السادس من بروتوكول الإنترنت، وتجري عملية التحصيص بحسب هرميةٍ مكونةٍ من المستويات الأربعة نفسها. في هذه الهرمية، يقع العميل الذي يحصل على فضاء جزئي مُخصص في قاعدة هرم التحصيص وهو المستوى الرابع والأخير في الهرمية، أمّا المستويات الثلاثة الأولى، فهي مرتبة بدءًا من رأس الهرم كما يلي: هيئة أرقام الإنترنت المُخصصَة، ثًمَّ [[سجل إنترنت إقليمي|سجلات الإنترنت الإقليمية]] ويليها [[سجل إنترنت إقليمي|سجلات الإنترنت المحلية]].<ref name="RFC-108">{{استشهاد مختصر|RFC 7020|ص=4-5|لغة=en}}</ref> |
||
|الأخير= Housley |
|||
|الأول= R. |
|||
|الأخير2= Curran |
|||
|الأول2= J. |
|||
|الأخير3= Huston |
|||
|الأول3= G. |
|||
|الأخير4= Conrad |
|||
|الأول4= D. |
|||
| تاريخ= أغسطس 2013 |
|||
| مسار أرشيف = https://web.archive.org/web/20200306033945/https://tools.ietf.org/html/rfc7020 |
|||
| مسار= https://tools.ietf.org/html/rfc7020 |
|||
| عنوان= RFC 7020, The Internet Numbers Registry System |
|||
| لغة= en |
|||
| صفحة = 4-5 |
|||
|doi= 10.17487/RFC7020 |
|||
| issn = 2070-1721 |
|||
|تاريخ أرشيف=2020-03-06}}</ref> |
|||
وضع آيكان سياسةً تُنظِّم عملية التحصيص، تُلزَم أيانا بموجبها على تقديم حصص من العناوين [[سجل إنترنت إقليمي|لسجلات الإنترنت الإقليمية]] تكفي حاجتها 18 |
وضع آيكان سياسةً تُنظِّم عملية التحصيص، تُلزَم أيانا بموجبها على تقديم حصص من العناوين [[سجل إنترنت إقليمي|لسجلات الإنترنت الإقليمية]] تكفي حاجتها 18 شهرًا على الأقل، على أن يكون طول البادئة الأدنى الذي تحصصه أيانا هو البادئة 12/.<ref group="Web">{{استشهاد ويب |
||
| مسار أرشيف = https://web.archive.org/web/20200228010449/https://www.icann.org/resources/pages/allocation-ipv6-rirs-2012-02-25-en |
| مسار أرشيف = https://web.archive.org/web/20200228010449/https://www.icann.org/resources/pages/allocation-ipv6-rirs-2012-02-25-en |
||
| تاريخ أرشيف = 28 فبراير 2020 |
| تاريخ أرشيف = 28 فبراير 2020 |
||
سطر 1٬112: | سطر 518: | ||
| موقع= icann.org |
| موقع= icann.org |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 8 مارس 2020}}</ref> توفِّر عملية التهيئة الذاتية الآلية {{إنج|Stateless address autoconfiguration اختصاراً SLAAC}} وسيلةً لعنونة [[مضيف (حوسبة)|المُضيفين]] |
| تاريخ الوصول= 8 مارس 2020}}</ref> توفِّر عملية التهيئة الذاتية الآلية {{إنج|Stateless address autoconfiguration اختصاراً SLAAC}} وسيلةً لعنونة [[مضيف (حوسبة)|المُضيفين]] آليًَّا باستعمال العناوين المحليَّة دون الحاجة لتدخلٍ يدويٍّ من قبل مدير الشبكة، حيث يجري ملء قسم مُعرِّف المنفذ اعتمادًا على مُعرِّفات المنافذ.<ref name="RFC-104"/> تحدد [[طلب تعليقات|وثيقة طلب التعليقات]] RFC 4291 العلاقة بين طول البادئة ومُعرِّف المنفذ في عنوان الإصدار السادس الذي يبلغ طوله 128 [[بت]]ًّا، فإذا كان طول البادئة هو n بت، فإن طول مُعرِّف المنفذ الملائم لعملية التهيئة الذاتية الآلية سيكون (128-n) بتًّا،<ref name="RFC-109"/> وتدعم الشركات المُصنِّعة لبطاقات الشبكة هذا المعيار أو تقدِّم حلولًا متوافقة معه، مثل حل المُعرِّف الفريد المُوسَّع الذي وضعه [[معهد مهندسي الكهرباء والإلكترونيات]] لإيجاد التوافق مع العنوان المادي في الإيثرنت الذي يبلغ طوله 48 بتًّا فقط.<ref name="Web-8">{{استشهاد مختصر|Guidelines|2017|ص=9-10|لغة=en}}</ref> أي يُستحسن أن يكون طول البادئة النهائي هو 64 بتًّا لإتاحة الفرصة لعملية التهيئة الذاتية الآلية |
||
| مسار أرشيف = https://web.archive.org/web/20200228003248/https://standards.ieee.org/content/dam/ieee-standards/standards/web/documents/tutorials/eui.pdf |
|||
| تاريخ أرشيف = 28 فبراير 2020 |
|||
| مسار= https://standards.ieee.org/content/dam/ieee-standards/standards/web/documents/tutorials/eui.pdf |
|||
| عنوان= Guidelines for Use of Extended Unique Identifier (EUI), Organizationally Unique Identifier (OUI), and Company ID (CID) |
|||
| موقع= IEEE |
|||
| صفحة = 9-10 |
|||
| تاريخ = 3 أغسطس 2017 |
|||
| لغة= en |
|||
| تاريخ الوصول= 8 مارس 2020}}</ref> أي يُستحسن أن يكون طول البادئة النهائي هو 64 بتاً لإتاحة الفرصة لعملية التهيئة الذاتية الآلية |
|||
نظريًَّا، خلال عمليتي التحصيص والتخصيص{{للهامش|10}} لعناوين الإصدار السادس من بروتوكول الإنترنت، يكون طول البادئة محصورًا بين البادئة 12/ وهو الطول الأدنى الذي تحصصه أيانا، والبادئة 64/، وهو الطول الأقصى اللازم لدعم عملية التهيئة الذاتية الآلية. عمليًَّا، حصصت أيانا بادئات بأطوال 23/ و12/ لسجلات الإنترنت الإقليمية<ref group="Web">{{استشهاد ويب |
|||
| مسار أرشيف = https://web.archive.org/web/20200216072542/https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xml |
| مسار أرشيف = https://web.archive.org/web/20200216072542/https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xml |
||
| تاريخ أرشيف = 16 فبراير 2020 |
| تاريخ أرشيف = 16 فبراير 2020 |
||
سطر 1٬130: | سطر 527: | ||
| موقع= IANA |
| موقع= IANA |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 8 مارس 2020}}</ref> التي قدمت بدورها |
| تاريخ الوصول= 8 مارس 2020}}</ref> التي قدمت بدورها حلولًا [[مزود خدمة الإنترنت|لمزودات الخدمة]] أو للعملاء على حد سواء، لمنح أفضية جزئيَّة متنوعة الأحجام ذات بادئات لا يتجاوز طولها البادئة 64/، وعلى سبيل المثال، يَدعم مركز تنسيق شبكة الإنترنت الأوروبي ({{اختصار مخفي|RIPE NCC|Réseaux IP Européens Network Coordination Centre}})، وهو [[سجل إنترنت إقليمي]]، حصصًا لأفضية جزئية ذات بادئات يتراوح طولها بين البادئتين 32/ و64/، ويشير إلى أن الأطوال الأكثر شعبية هي للبادئتين 48/ و56/ وهي تضم على التوالي: 65,536 و256 شبكة جزئية مُحددة بالبادئة 64/.<ref group="Web">{{استشهاد ويب |
||
| مسار أرشيف = https://web.archive.org/web/20200215034209/https://www.ripe.net/about-us/press-centre/understanding-ip-addressing |
| مسار أرشيف = https://web.archive.org/web/20200215034209/https://www.ripe.net/about-us/press-centre/understanding-ip-addressing |
||
| تاريخ أرشيف = 15 فبراير 2020 |
| تاريخ أرشيف = 15 فبراير 2020 |
||
سطر 1٬142: | سطر 539: | ||
==== التجزئة ==== |
==== التجزئة ==== |
||
[[ملف:IPv6 CIDR table-ar.svg|تصغير|300بك|جدول لأطوال بادئة التوجيه غير الصنفي بين النطاقات في الإصدار السادس من بروتوكول الإنترنت وأعداد الشبكات الجزئية الموافقة لكل منها وعدد بتات قسم مُعرف المنفذ.]] |
[[ملف:IPv6 CIDR table-ar.svg|تصغير|300بك|جدول لأطوال بادئة التوجيه غير الصنفي بين النطاقات في الإصدار السادس من بروتوكول الإنترنت وأعداد الشبكات الجزئية الموافقة لكل منها وعدد بتات قسم مُعرف المنفذ.]] |
||
[[ملف:Subnet Identifier Boundaries in IPv6-ar.svg|تصغير|300بك|حالات حدود معرف الشبكة الجزئية (SID) في |
[[ملف:Subnet Identifier Boundaries in IPv6-ar.svg|تصغير|300بك|حالات حدود معرف الشبكة الجزئية (SID) في الإصدار السادس من بروتوكول الإنترنت.]] |
||
يُقسّم مجال فضاء العناوين في الإصدار السادس من بروتوكول الإنترنت إلى مجموعة من الأفضية الجزئية بحسب الغرض من الاستخدام.<ref name="RFC-64"/> وتدير [[أيانا|هيئة أرقام الإنترنت المُخصصة]] عملية تحصيص الأفضية، ومنها عملية تحصيص فضاء عناوين البث فريد الوجهة، وفيها تجري عملية منح العناوين الفريدة |
يُقسّم مجال فضاء العناوين في الإصدار السادس من بروتوكول الإنترنت إلى مجموعة من الأفضية الجزئية بحسب الغرض من الاستخدام.<ref name="RFC-64"/> وتدير [[أيانا|هيئة أرقام الإنترنت المُخصصة]] عملية تحصيص الأفضية، ومنها عملية تحصيص فضاء عناوين البث فريد الوجهة، وفيها تجري عملية منح العناوين الفريدة عالميًّا على أساس جغرافي، وفق بنية هرمية تسمح باستعمال تقنيات [[توجيه بين نطاقي غير صنفي|التوجيه غير الصنفي بين النطاقات]] لاختزال عناوين الأفضية، والغرض من ذلك استقرار [[جدول توجيه|جداول التوجيه]] على المستوى العالمي، تخصص هيئة أرقام الإِنترنت المُخصَّصة أفضية عناوين لسجلات الإنترنت الإقليمية، عن طريق منحها بادئات بطول 23 [[بت]].<ref group="Web">{{استشهاد ويب |
||
| مؤلف = |
| مؤلف = |
||
| مسار أرشيف = https://web.archive.org/web/20180222014929/https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml |
| مسار أرشيف = https://web.archive.org/web/20180222014929/https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml |
||
سطر 1٬153: | سطر 550: | ||
| موقع= IANA |
| موقع= IANA |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 2 سبتمبر 2018}}</ref> بعد ذلك، يقوم كل [[سجل إنترنت إقليمي]] بتجزئة فضاء العناوين إلى أفضية عناوين جزئية تمنح [[مزود خدمة الإنترنت|لمزودات الخدمة]]، وقد تحصل عملية المنح على أكثر من مستوى، مثل منح فضاء عناوين لمزود خدمة وطني ليقوم بتجزئته إلى أفضية أصغر تمنح لمزودات الخدمة المحلية.<ref |
| تاريخ الوصول= 2 سبتمبر 2018}}</ref> بعد ذلك، يقوم كل [[سجل إنترنت إقليمي]] بتجزئة فضاء العناوين إلى أفضية عناوين جزئية تمنح [[مزود خدمة الإنترنت|لمزودات الخدمة]]، وقد تحصل عملية المنح على أكثر من مستوى، مثل منح فضاء عناوين لمزود خدمة وطني ليقوم بتجزئته إلى أفضية أصغر تمنح لمزودات الخدمة المحلية.<ref group="Web">{{استشهاد ويب |
||
| مؤلف = |
| مؤلف = |
||
| مسار أرشيف = https://web.archive.org/web/20180826010744/https://www.ripe.net/about-us/press-centre/understanding-ip-addressing |
| مسار أرشيف = https://web.archive.org/web/20180826010744/https://www.ripe.net/about-us/press-centre/understanding-ip-addressing |
||
سطر 1٬159: | سطر 556: | ||
| تاريخ = 4 يناير 2011 |
| تاريخ = 4 يناير 2011 |
||
| مسار= https://www.ripe.net/about-us/press-centre/understanding-ip-addressing |
| مسار= https://www.ripe.net/about-us/press-centre/understanding-ip-addressing |
||
| تاريخ أرشيف = 23 سبتمبر 2018 |
|||
| عنوان= Understanding IP Addressing and CIDR Charts |
| عنوان= Understanding IP Addressing and CIDR Charts |
||
| موقع= RIPE |
| موقع= RIPE |
||
سطر 1٬165: | سطر 561: | ||
| تاريخ الوصول= 23 سبتمبر 2018}}</ref> |
| تاريخ الوصول= 23 سبتمبر 2018}}</ref> |
||
يحصل المُشتركون على أفضية عناوين جزئية من مزودات الخدمة المحلية، وتكون البادئة عادة بطول 48 بت، في الغالب الأعم يقتطع مديرو الشبكات |
يحصل المُشتركون على أفضية عناوين جزئية من مزودات الخدمة المحلية، وتكون البادئة عادة بطول 48 بت، في الغالب الأعم يقتطع مديرو الشبكات قسمًا يبلغ طوله 16 بت من مُعرف المنفذ، ويُنشؤون قسمًا جديدًا هو مُعرّف الشبكة الجزئية الذي يُضاف إلى البادئة فيصبح طولها النهائي 64 بت، ويترك ذلك 64 بت لمُعرّف المنفذ، وهو طول ملائم لآلية توليد المُعرّف الفريد المُوسّع.<ref name = "Book-18">{{استشهاد مختصر|Odom|2013|ص=639|لغة=en}}</ref> |
||
إن التجزئة في الإصدار السادس من بروتوكول الإنترنت تتشابه من حيث الآلية الرياضية مع |
إن التجزئة في الإصدار السادس من بروتوكول الإنترنت تتشابه من حيث الآلية الرياضية مع التجزئة في الإصدار الرابع، لكنها تختلف من حيث الغاية، فهي تهدف إلى تنظيم استعمال فضاء العناوين بطريقة متوافقة مع آلية التوجيه، ولا تستخدم لتحديد حجم محدد من أفضية العناوين كما في الحالة في الإصدار الرابع، فعدد العناوين المتاحة في شبكة جزئية واحد من الإصدار السادس طول بادئتها 64 بت، يبلغ المليارات، وهو بحد ذاته، أكبر من كامل فضاء عناوين [[بروتوكول الإنترنت (الإصدار الرابع)|الإصدار الرابع من بروتوكول الإنترنت]].<ref name="Book-19">{{استشهاد مختصر|Kozierok|2005|ص=464|لغة=en}}</ref> |
||
|مؤلف1= Charles M. Kozierok |
|||
|عنوان= The TCP/IP Guide |
|||
|مسار= https://web.archive.org/web/20180829142218/http://lepointdeau.fr/The%20TCP%20IP%20Guide.pdf |
|||
|سنة=2005 |
|||
|ناشر= William Pollock |
|||
|الرقم المعياري= 1-59327-047-X |
|||
| صفحة = 464 |
|||
|لغة= en |
|||
| مسار أرشيف = https://web.archive.org/web/20200602073347/https://web.archive.org/web/20180829142218/http://lepointdeau.fr/The%20TCP%20IP%20Guide.pdf | تاريخ أرشيف = 2 يونيو 2020 }}</ref> |
|||
يتكون عنوان الإصدار السادس من بروتوكول الإنترنت من 128 بت، ويكتب بنظام العد الست عشري على شكل عدد مكوّن من 32 مرتبة ست عشرية، ويجري تجميع هذه المراتب ضمن رباعيات عددها 8 يضم كل منها |
يتكون عنوان الإصدار السادس من بروتوكول الإنترنت من 128 بت، ويكتب بنظام العد الست عشري على شكل عدد مكوّن من 32 مرتبة ست عشرية، ويجري تجميع هذه المراتب ضمن رباعيات عددها 8 يضم كل منها 4 مراتب ست عشرية أو 16 بت.<ref name="Book-12" /> عند تجزئة فضاء عناوين من الإصدار السادس، يجري اقتطاع قسم من مُعرّف المنفذ وإنشاء قسم جديد هو معرف الشبكة الجزئية، يمكن وفقًا لموقع نهاية مُعرّف الشبكة الجزئية ضمن العنوان التمييز بين الحالات التالية: |
||
# مُعرّف الشبكة الجزئية ينتهي عند حدود إحدى المجموعات الرباعية، ويعني ذلك أن نهاية المُعرّف تكون عند أحد البتات ذوات الفهارس {''15,31,47,63,79,95,111,127''}. |
# مُعرّف الشبكة الجزئية ينتهي عند حدود إحدى المجموعات الرباعية، ويعني ذلك أن نهاية المُعرّف تكون عند أحد البتات ذوات الفهارس {''15,31,47,63,79,95,111,127''}. |
||
# مُعرّف الشبكة الجزئية ينتهي عند حدود إحدى المراتب الست عشرية ضمن مجموعة رباعية، |
# مُعرّف الشبكة الجزئية ينتهي عند حدود إحدى المراتب الست عشرية ضمن مجموعة رباعية، وتوجد 3 حالات ممكنة في كل مجموعة رباعية، مثلًا في المجموعة الأولى هي البتات ذات الفهارس {''3,7,11''} وفي الثانية {''19,23,27''} وهكذا.. |
||
# مُعرّف الشبكة الجزئية ينتهي عند حدود أحد البتات ضمن خانة ست عشرية داخل مجموعة رباعية، |
# مُعرّف الشبكة الجزئية ينتهي عند حدود أحد البتات ضمن خانة ست عشرية داخل مجموعة رباعية، وتوجد 3 حالات ممكنة في ضمن كل خانة ست عشرية، مثلًا في الخانة الست عشرية الثانية تكون الحدود الممكنة عند البتات ذات الفهارس {''4,5,6''} وفي الخانة الست عشرية الثالثة عند البتات ذات الفهارس {''8,9,10''} وهكذا.{{للهامش|11}} |
||
''' أمثلة عن التجزئة في الإصدار السادس من بروتوكول الإنترنت:''' |
''' أمثلة عن التجزئة في الإصدار السادس من بروتوكول الإنترنت:''' |
||
سطر 1٬196: | سطر 583: | ||
[[ملف:IPv6 Fragmentation Concept-ar.svg|تصغير|300بك|المبدأ العام للتقطيع في الإصدار السادس من بروتوكول الإنترنت.]] |
[[ملف:IPv6 Fragmentation Concept-ar.svg|تصغير|300بك|المبدأ العام للتقطيع في الإصدار السادس من بروتوكول الإنترنت.]] |
||
{{مفصلة|تقطيع (شبكات)#التقطيع في الإصدار السادس من بروتوكول الإنترنت}} |
{{مفصلة|تقطيع (شبكات)#التقطيع في الإصدار السادس من بروتوكول الإنترنت}} |
||
تقطيع رزمة البيانات وإعادة تجميعها هو وظيفة من وظائف الإصدار السادس من بروتوكول الإنترنت. تحصل عملية التقطيع في المضيف المصدر عندما يكون |
تقطيع رزمة البيانات وإعادة تجميعها هو وظيفة من وظائف الإصدار السادس من بروتوكول الإنترنت. تحصل عملية التقطيع في المضيف المصدر عندما يكون طول الرزمة أكبر من [[وحدة النقل العظمى]] للمسار كاملًا، وفيه تُقطَّع حمولة رزمة البيانات الأصلية إلى عدد من القطع ويُضاف لكل منها ترويسة البروتوكول وترويسة القطعة، وتُرسَل القطع إلى وجهة الرزمة الأصلية حيث يُصار إلى تجميعها. من أجل كل عملية تقطيع، يُولِّد المُضيف المصدر قيمة مُميزة تستعمل مُعرِّفًا، وتوضع في حقل المُعرِّف في ترويسة القطعة، وبهذا يمكن للمضيف الوجهة التعرُّف على القطع التي نتجت عن عملية تقطيع واحدة، في الحالات التي يستقبل فيها قطعًا ناتجة عن أكثر من عملية تقطيع من المصدر نفسه.<ref name="RFC-110">{{استشهاد مختصر|RFC 8200|ص=15|لغة=en}}-22</ref> |
||
نظريًّا، يمكن إرسال رزمة بيانات تبلغ من الطول 65535 بايتًا من غير تقطيعها ولكن غالبًا ما يلزم التقطيع للتماشي مع طول نقل أعظم أقل من هذه القيمة مُحدد سلفًا في طبقة الوصلة، أما طول رزمة البيانات الأدنى الذي يدعمه البروتوكول فهو 1280 بايت.<ref name="Book-21"/> يدعم البروتوكول أيضًا الرزم العملاقة {{إنج|Jumbogram}}، وهي رزم بيانات يتراوح طولها بين 2<sup>16</sup>=65535 و2<sup>32</sup>=4294967295 بايت وتستخدم في شبكات بيانات تدعم أحجام نقل عظمى أكبر من 65535.<ref name="RFC-111">{{استشهاد مختصر|RFC 2675|ص=1|لغة=en}}</ref> |
|||
| الأخير= Borman |
|||
| الأول= D. |
|||
| الأخير= Deering |
|||
| الأول= S. |
|||
| الأخير= Hinden |
|||
| الأول= R. |
|||
| تاريخ=أغسطس 1999 |
|||
| مسار أرشيف = https://web.archive.org/web/20200503043203/https://tools.ietf.org/html/rfc2675 |
|||
| مسار= https://tools.ietf.org/html/rfc2675 |
|||
| عنوان= RFC 2675, IPv6 Jumbograms |
|||
| موقع=The Internet Society |
|||
| صفحة =1 |
|||
| لغة= en |
|||
| doi = 10.17487/RFC2675 |
|||
| ISSN = |
|||
|تاريخ أرشيف=2020-05-03}}</ref> |
|||
==== التقطيع ==== |
==== التقطيع ==== |
||
[[ملف:IPv6 Fragmentation algorithm-ar.svg|تصغير|300بك| مخطط |
[[ملف:IPv6 Fragmentation algorithm-ar.svg|تصغير|300بك| مخطط تدفقي يبين خوارزمية عملية التقطيع في الإصدار السادس من بروتوكول الإنترنت.]] |
||
يعامِل المُضيف المصدر رزمة البيانات التي يريد تقطيعها على أنها مكوِّنة من ثلاثة أجزاء:<ref name="RFC-112">RFC 8200 |
يعامِل المُضيف المصدر رزمة البيانات التي يريد تقطيعها على أنها مكوِّنة من ثلاثة أجزاء:<ref name="RFC-112">{{استشهاد مختصر|RFC 8200|ص=17|لغة=en}}</ref> |
||
# '''الترويسات التي ستوضع في القطع كلها''': تضم هذه [[ترويسة (حوسبة)|الترويسات]] ترويسة الإصدار السادس وترويسات التوسعة التالية لها حتى ترويسة التوجيه، إن وجدت، وإلا فحتى ترويسة خيارات المسار، إن وجدت، فإن غابت الترويستان السابقتان ضمَّ هذا الجزء ترويسة الإصدار السادس فقط. |
# '''الترويسات التي ستوضع في القطع كلها''': تضم هذه [[ترويسة (حوسبة)|الترويسات]] ترويسة الإصدار السادس وترويسات التوسعة التالية لها حتى ترويسة التوجيه، إن وجدت، وإلا فحتى ترويسة خيارات المسار، إن وجدت، فإن غابت الترويستان السابقتان ضمَّ هذا الجزء ترويسة الإصدار السادس فقط. |
||
# '''ترويسات التوسعة والطبقات العليا''': وتضم جميع ترويسات التوسعة الأخرى التي لم تُشمل في القسم السابق، أما ترويسات الطبقات العليا فتشمل جميع الترويسات التي ليست ترويسات توسعة مثل ترويسات [[بروتوكول التحكم بالنقل]] و[[بروتوكول حزم بيانات المستخدم]] أو ترويسة بروتوكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت.{{للهامش|12}} |
# '''ترويسات التوسعة والطبقات العليا''': وتضم جميع ترويسات التوسعة الأخرى التي لم تُشمل في القسم السابق، أما ترويسات الطبقات العليا فتشمل جميع الترويسات التي ليست ترويسات توسعة مثل ترويسات [[بروتوكول التحكم بالنقل]] و[[بروتوكول حزم بيانات المستخدم]] أو ترويسة بروتوكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت.{{للهامش|12}} |
||
# '''الحمولة''': وهي القسم الذي سوف يُقطَّع، ويبدأ بعد ترويسات الطبقات العليا. |
# '''الحمولة''': وهي القسم الذي سوف يُقطَّع، ويبدأ بعد ترويسات الطبقات العليا. |
||
تجري عملية التقطيع وفق الخطوات التالية:<ref name="RFC-113">RFC 8200 |
تجري عملية التقطيع وفق الخطوات التالية:<ref name="RFC-113">{{استشهاد مختصر|RFC 8200|ص=17-19|لغة=en}}</ref> |
||
# تحديد طول رزمة الإصدار السادس التي ستنتج عن التقطيع. |
# تحديد طول رزمة الإصدار السادس التي ستنتج عن التقطيع. |
||
# إنشاء القطعة الأولى، وهي تتضمن ما يأتي |
# إنشاء القطعة الأولى، وهي تتضمن ما يأتي وفقًا لتسلسل الورود: الترويسات التي ستوضع في القطع كلها وترويسة القطعة وترويسات التوسعة والطبقات العليا وقطعة من الحمولة، يحدد طولها كما يأتي: |
||
## يُحسب مجموع أطوال الترويسات التي ستوضع في القطع كلها وترويسة القطعة وترويسات التوسعة والطبقات العليا. |
## يُحسب مجموع أطوال الترويسات التي ستوضع في القطع كلها وترويسة القطعة وترويسات التوسعة والطبقات العليا. |
||
## يُطرح المجموع من طول رزمة الإصدار السادس المُحدد بالخطوة الأولى، والناتج هو طول حمولة القطعة الأولى. |
## يُطرح المجموع من طول رزمة الإصدار السادس المُحدد بالخطوة الأولى، والناتج هو طول حمولة القطعة الأولى. |
||
# تُقتطع حمولة القطعة الأولى من حمولة الرزمة الأصلية. |
# تُقتطع حمولة القطعة الأولى من حمولة الرزمة الأصلية. |
||
# تحديد عدد القطع اللازم تقطيعها بتقسيم حمولة الرزمة الأصلية، بعد اقتطاع حمولة القطعة الأولى، على طول الرزمة المُحدد بالخطوة الأولى، إذا كان الجواب |
# تحديد عدد القطع اللازم تقطيعها بتقسيم حمولة الرزمة الأصلية، بعد اقتطاع حمولة القطعة الأولى، على طول الرزمة المُحدد بالخطوة الأولى، إذا كان الجواب كسريًّا، فإن القسم الصحيح هو عدد القطع الوسطى، أي التي تقع بين القطعتين الأولى والأخيرة، وأما الجزء الكسري، فيمثل القطعة الأخيرة. |
||
# تقسم حمولة الرزمة الأصلية، بعد اقتطاع حمولة القطعة الأولى، إلى عدد القطع المحددة بالخطوة الرابعة. |
# تقسم حمولة الرزمة الأصلية، بعد اقتطاع حمولة القطعة الأولى، إلى عدد القطع المحددة بالخطوة الرابعة. |
||
# إنشاء القطع الوسطى: تتضمن القطع الوسطى الترويسات التي ستوضع في القطع كلها وترويسة القطعة وقطعة من الحمولة الناتجة عن الخطوة الخامسة ما خلا القطعة الأخيرة إذا كان عدد القطع |
# إنشاء القطع الوسطى: تتضمن القطع الوسطى الترويسات التي ستوضع في القطع كلها وترويسة القطعة وقطعة من الحمولة الناتجة عن الخطوة الخامسة ما خلا القطعة الأخيرة إذا كان عدد القطع كسريًّا. |
||
# إنشاء القطعة الأخيرة: وتتضمَّن الترويسات التي ستوضع في القطع كلها وترويسة القطعة والقطعة الأخيرة من الحمولة الناتجة عن الخطوة الخامسة. |
# إنشاء القطعة الأخيرة: وتتضمَّن الترويسات التي ستوضع في القطع كلها وترويسة القطعة والقطعة الأخيرة من الحمولة الناتجة عن الخطوة الخامسة. |
||
==== إعادة التجميع ==== |
==== إعادة التجميع ==== |
||
[[ملف:Reassemled packet-ar.svg|تصغير|300 بك|بنية رزمة بيانات الإصدار السادس من بروتوكول الإنترنت الناتجة عن إعادة تجميع القطع في المضيف الوجهة.]] |
[[ملف:Reassemled packet-ar.svg|تصغير|300 بك|بنية رزمة بيانات الإصدار السادس من بروتوكول الإنترنت الناتجة عن إعادة تجميع القطع في المضيف الوجهة.]] |
||
تحصل عملية إعادة التجميع في المضيف الوجهة فقط، وفيه تُستخلص حمولة القطع المُستقبلة ويُعاد ترتيبها وفقا لموقعها الأصلي المُحدد بحقل إزاحة القطعة، ويُصار إلى تشكيل رزمة البيانات الأصلية كما كانت قبل |
تحصل عملية إعادة التجميع في المضيف الوجهة فقط، وفيه تُستخلص حمولة القطع المُستقبلة ويُعاد ترتيبها وفقا لموقعها الأصلي المُحدد بحقل إزاحة القطعة، ويُصار إلى تشكيل رزمة البيانات الأصلية كما كانت قبل التقطيع في المضيف المصدر. يُشترط أن يكون عنوان المصدر وعنوان الوجهة وقيمة الحقل المُعرِّف متطابقة في جميع القطع التي سيعاد تجميعها. لإعادة تجميع الرزمة الأصلية، يبدأ المضيف الوجهة بإنشاء ترويسة الإصدار السادس من بروتوكول الإنترنت، ثُمَّ يستخلص أيضًا نسخة من الترويسات الموجودة في كل قطعة، ويضيفها بعد ترويسة البروتوكول، ويضيف بعدها أيضًا ترويسات التوسعة وترويسات الطبقات العليا إن وجدت، مع الانتباه لقيمة حقل الترويسة التالية في كل منها للحفاظ على تتابع الترويسات بشكلٍ سليم. بعد ذلك يحدد المضيف الوجهة الموقع النسبي لكل قطعة من الحمولة في رزمة البيانات الأصلية مُشكلًا حمولة الرزمة الأصلية، ثم يَحسب طول هذه الحمولة ويضيفه إلى ترويسة الإصدار السادس، وأخيرًا تُغلَّف الحمولة وترويسات الطبقات العليا والتوسعة وترويسة الإصدار السادس من بروتوكول الإنترنت داخل رزمة بيانات جديدة تتطابق مع رزمة البيانات الأصيلة قبل التقطيع.<ref name="RFC-114">{{استشهاد مختصر|RFC 8200|ص=20|لغة=en}}</ref> |
||
=== إدارة حركة البيانات === |
=== إدارة حركة البيانات === |
||
==== تعريف تدفقات حركة البيانات ==== |
==== تعريف تدفقات حركة البيانات ==== |
||
يُستعمل حقل لافتة التدفق في ترويسة الإصدار السادس من بروتوكول الإنترنت لتعريف تدفق من رزم البيانات. |
يُستعمل حقل لافتة التدفق في ترويسة الإصدار السادس من بروتوكول الإنترنت لتعريف تدفق من رزم البيانات. وفقًا لمعيار البروتوكول، فإن [[رزمة بيانات|رزم البيانات]] تنتمي لتدفق محدد إذا تطابقت ثلاثُ قيم فيها: عنوان مصدرها، وعنوان وجهتها وقيمة حقل لافتة التدفق فيها. تصنَّف رزم البيانات في الشبكة وفقًا للتدفق الذي تنتمي إليه، ثُمَّ تعامل على هذا الأساس، ويختص البروتوكول بتعريف آلية لتمييز تدفق الرزم، أما نوعية الخدمات المُقدَّمة للتدفقات فهي خارج نطاق محدداته.<ref name="RFC-115">RFC 6437, P.4</ref> |
||
يبلغ طول حقل اللافتة 20 [[بت |
يبلغ طول حقل اللافتة 20 [[بت]]ًّا، ويلزم أن يختار المضيف المصدر قيمته بشكل عشوائي وفريد بحيث لا يُولِّد مُعرفين متطابقي القيمة لأجل تدفقين مختلفين في الوقت نفسه. إذا كانت قيمة حقل اللافتة صفرية، فهذا يعني أن رزمة البيانات لا تنتمي لأي تدفق. بخلاف ذلك، فإن أي قيمة عددية يمكن تمثيلها باستعمال 20 بتًّا تصلح للاستخدام كمُعرِّف للتدفق.<ref name="RFC-116">RFC 6437, P.5</ref> |
||
==== تصنيف حركة البيانات ==== |
==== تصنيف حركة البيانات ==== |
||
[[ملف:IPv6 Traffic Class Field Structure-ar.svg|تصغير|300بك|بنية حقل صنف حركة البيانات في ترويسة الإصدار البروتوكول.]] |
[[ملف:IPv6 Traffic Class Field Structure-ar.svg|تصغير|300بك|بنية حقل صنف حركة البيانات في ترويسة الإصدار البروتوكول.]] |
||
وهي آلية للتمييز بين رزم بيانات الإصدار السادس من بروتوكول الإنترنت |
وهي آلية للتمييز بين رزم بيانات الإصدار السادس من بروتوكول الإنترنت اعتمادًا على قيم حقل صنف حركة البيانات ذي البتات الثمانية في ترويسة البروتوكول، تُضبط هذه القيم هي العقدة المصدر أو في العقد التي تعالج الرزمة على طول المسار. بعد ذلك، تُمنح الخدمات وأولوية المعالجة للرزم بناء على قيمة هذا الحقل.<ref name="RFC-117">RFC 2460, P.25</ref> طُبقت آلية مشابهة في الإصدار الرابع من بروتوكول الإنترنت، وسُمي الحقل المختص بها في ترويسة البروتوكول بحقل توع الخدمة، وكان طوله 8 بت أيضًا.<ref name="RFC-118">RFC 2460, P.29-30</ref> |
||
يُقسَّم حقل صنف حركة البيانات إلى قسمين، هما قسم موقع ترميز الخدمات المتمايزة {{إنج|Differentiated services codepoint}} ويشغل البتات الستة الأكثر أهمية من الحقل، وقسم البتات غير المُستعملة ويشمل البتين الأخيرين.<ref name="RFC-119">RFC 2474 |
يُقسَّم حقل صنف حركة البيانات إلى قسمين، هما قسم موقع ترميز الخدمات المتمايزة {{إنج|Differentiated services codepoint}} ويشغل البتات الستة الأكثر أهمية من الحقل، وقسم البتات غير المُستعملة ويشمل البتين الأخيرين.<ref name="RFC-119">{{استشهاد مختصر|RFC 2474|ص=7|لغة=en}}</ref> وتحدد الوثيقة RFC 2474 بنية محددة لقسم موقع الترميز هي: "xxx000" حيث تُمثِّل x بتًّا واحدًا قد تكون قيمته 0 أو 1، ويسمح ذلك بإنشاء 8 أصناف متمايزة لرزم البيانات.<ref name="RFC-120">{{استشهاد مختصر|RFC 2474|ص=11|لغة=en}}</ref> يُحجز الترميز "000000" ليكون القيمة الافتراضية الدائمة لهذا الحقل، أما القيم السبعة الأخرى، أي {"001000"، "010000"، "011000"... "111000"}، فهي قابلة للتهيئة وفقًا للحاجة ولتعريف مستويات جودة الخدمة المطلوبة.<ref name="RFC-121">{{استشهاد مختصر|RFC 2474|ص=13|لغة=en}}</ref> |
||
== المُشكلات == |
== المُشكلات == |
||
سطر 1٬254: | سطر 625: | ||
=== مرتبطة بتقطيع البيانات === |
=== مرتبطة بتقطيع البيانات === |
||
ينتج عن استخدام التقطيع في الإصدار السادس من بروتوكول الإنترنت عدد من [[ثغرة أمنية (حوسبة)|الثغرات |
ينتج عن استخدام التقطيع في الإصدار السادس من بروتوكول الإنترنت عدد من [[ثغرة أمنية (حوسبة)|الثغرات الأمنيّة]] التي قد تستخدم لشن هجمات مثل هجوم القطعة الصغيرة أو هجوم القطع المتراكبة، وتختلف إمكانية شن الهجمات وفقًا [[نظام تشغيل|لنظام التشغيل]] الذي يستعمل البروتوكول.<ref name = "REF-20" group="ar">{{استشهاد مختصر|1=بكني|ص=2022|ص=233}}</ref> بشكلٍ مُشابه [[بروتوكول الإنترنت (الإصدار الرابع)|للإصدار الرابع من بروتوكول الإنترنت]]، لم تمنع مُحددات الإصدار السادس إنشاء قطع متراكبة عند التقطيع، أي من الممكن أن يتكرر المقطع نفسه من [[حمولة (حوسبة)|الحمولة]] في أكثر من قطعة، على أن يُعتمد المقطع الوارد في آخر قطعة تمّ استقبالها عند التجميع، يسبب ذلك ثغرة أمنية، ويسمح بتنفيذ هجوم القطع المتراكبة، لاحقًا أُكِّد بوضوح على منع تراكب القطع عند التقطيع في [[طلب تعليقات|وثيقة طلب التعليقات]] RFC 5722.<ref name="RFC-122">{{استشهاد مختصر|RFC 5722|ص=1|لغة=en}}</ref> |
||
|الأخير= Atlasis |
|||
|الأول= Antonios |
|||
|صحيفة = Black-Hat Europe |
|||
|عنوان= Attacking IPv6 Implementation Using Fragmentation |
|||
|سنة= 2002 |
|||
| مسار = https://docs.huihoo.com/blackhat/europe-2012/bh-eu-12-Atlasis-Attacking_IPv6-WP.pdf |
|||
| مسار أرشيف = https://web.archive.org/web/20200325133126/https://docs.huihoo.com/blackhat/europe-2012/bh-eu-12-Atlasis-Attacking_IPv6-WP.pdf | تاريخ أرشيف = 25 مارس 2020 }}</ref> بشكلٍ مُشابه [[بروتوكول الإنترنت (الإصدار الرابع)|للإصدار الرابع من بروتوكول الإنترنت]]، لم تمنع مُحددات الإصدار السادس إنشاء قطع متراكبة عند التقطيع، أي من الممكن أن يتكرار نفس المقطع من [[حمولة (حوسبة)|الحمولة]] في أكثر من قطعة، على أن يُعتمد المقطع الوارد في آخر قطعة تمّ استقبالها عند التجميع، يسبب ذلك ثغرة أمنية، ويسمح بتنفيذ هجوم القطع المتراكبة، لاحقاً تمّ التأكيد بوضوح على منع تراكب القطع عند التقطيع في [[طلب تعليقات|وثيقة طلب التعليقات]] RFC 5722.<ref name="RFC-122">{{استشهاد ويب |
|||
| الأخير= Krishnan |
|||
| الأول= S. |
|||
| تاريخ= فبراير 2016 |
|||
| مسار= https://tools.ietf.org/html/rfc5722 |
|||
| عنوان= RFC 5722, Handling of Overlapping IPv6 Fragments |
|||
| موقع= The Internet Society |
|||
| لغة= en |
|||
| تاريخ الوصول= 21 يوليو 2018 |
|||
|مسار أرشيف= https://web.archive.org/web/20200511010753/https://tools.ietf.org/html/rfc5722|تاريخ أرشيف=2020-05-11}}</ref> |
|||
يقبل [[مضيف (حوسبة)|مُضيف]] الإصدار السادس من بروتوكول الإنترنت أن تحتوي [[رزمة بيانات|رزمة البيانات]] على [[ترويسة]] القطعة |
يقبل [[مضيف (حوسبة)|مُضيف]] الإصدار السادس من بروتوكول الإنترنت أن تحتوي [[رزمة بيانات|رزمة البيانات]] على [[ترويسة (حوسبة)|ترويسة]] القطعة من غير أن تكون القطعة ناتجة عن عملية تقطيع، وتسمى هذه القطع بالقطع الذرية {{إنج|Atomic Fragment}} وهي تنتج في حالات خاصة ناقشها المعيار الأصلي للبروتوكول،<ref name="RFC-129">{{استشهاد مختصر|RFC 8200|ص=31|لغة=en}}</ref> على الرغم من أن هذه القطع تكون وحدانًا، أي لا يجب تجميعها مع أي قطع أخرى، فإنّ المُضيف الوجهة يعاملها مُعاملة القطع التي تنتظر التجميع، ما يُسبب ثغرة أمنية، فقد يرسل المهاجم قطعة خبيثة مع قيم مُناسبة في ترويسة القطعة، بحيث تكون قطعة ذرية تقبل التجميع مع قطع أخرى خبيثة تُرسل لاحقًا، ناقشت الوثيقة RFC 6946 كيفية معالجة القطع الذرية لتلافي هذا النوع من الهجمات.<ref name="RFC-123">{{استشهاد مختصر|RFC 6946|ص=1|لغة=en}}</ref> |
||
| الأخير= Gont |
|||
| الأول= F. |
|||
| تاريخ= مايو 2013 |
|||
| مسار= https://tools.ietf.org/html/rfc6946 |
|||
| عنوان= RFC 6946, Processing of IPv6 "Atomic" Fragments |
|||
| موقع= The Internet Society |
|||
| لغة= en |
|||
| issn = 2070-1721 |
|||
| تاريخ الوصول= 21 يوليو 2018 |
|||
|مسار أرشيف= https://web.archive.org/web/20200311231631/https://tools.ietf.org/html/rfc6946|تاريخ أرشيف=2020-03-11}}</ref> |
|||
=== مرتبطة بإدارة حركة البيانات === |
=== مرتبطة بإدارة حركة البيانات === |
||
يُمكن تزوير قيمة حقل لافتة التدفق في رزمة بيانات ما من أجل حصولها على خدمة محددة أو معاملة تفضيلية عند معالجتها،<ref name="RFC-124">RFC 6437 |
يُمكن تزوير قيمة حقل لافتة التدفق في رزمة بيانات ما من أجل حصولها على خدمة محددة أو معاملة تفضيلية عند معالجتها،<ref name="RFC-124">{{استشهاد مختصر|RFC 6437|ص=9|لغة=en}}</ref> ولا توجد طريقة لحماية حقل التدفق في ترويسة البروتوكول من العبث حتى ولو استعملت حزمة بروتوكول الإنترنت الأمنية،<ref name="RFC-125">{{استشهاد مختصر|RFC 6437|ص=10|لغة=en}}</ref> ويُشكِّل هذا ثغرة أمنية، ويُستحسن أن تكون قيمة هذا الحقل شبه عشوائية بحيث يصعب على المهاجم تخمين قيمة المعرف المُستعمل.<ref name = "REF-20" group="ar"/> يُمكن أيضًا أن تُستخدم قيمة حقل لافتة التدفق من أجل إجراء تحليل لحركة البيانات في الشبكة، أو لتتبع حركة بيانات مُحددة. وحتى لو [[علم التعمية|عُمِّيت]] الرسالة، فإن تعمية قيمة ثابتة غير متغيرة قد ينتج قيمًا ثابتة في الرسالة المعماة تساعد في تحليلها أو في كشف آلية [[علم التعمية|التعمية]] أو في كشف ترتيب البيانات في الرسالة.<ref name="RFC-126">{{استشهاد مختصر|RFC 6437|ص=8|لغة=en}}</ref> |
||
|الأخير= Gont |
|||
|الأول= F. |
|||
| تاريخ= 12 مارس 2012 |
|||
| مسار= https://tools.ietf.org/html/rfc7020 |
|||
| عنوان= Security Assessment of the IPv6 Flow Label draft-gont-6man-flowlabel-security-03 |
|||
| لغة= en |
|||
||مسار أرشيف= https://web.archive.org/web/20200520020436/https://tools.ietf.org/html/rfc7020|تاريخ أرشيف=2020-05-20}}</ref> يُمكن أيضاً أن تُستخدم قيمة حقل لافتة التدفق من أجل إجراء تحليل لحركة البيانات في الشبكة، أو لتتبع حركة بيانات مُحددة. وحتى لو جرى تشفير الرسالة، فإن تشفير قيمة ثابتة غير متغيرة قد ينتج قيماً ثابتة في الرسالة المُشفرة تساعد في تحليلها أو في كشف آلية التشفير أو في كشف ترتيب البيانات في الرسالة.<ref name="RFC-126">RFC 6437, P.8</ref> |
|||
يوجد هجوم يُسمى هجوم سرقة الخدمة {{إنج|Theft of Service}} وفيه تُغيَّر قيمة حقل صنف الخدمة في رزمة بيانات ما من أجل زيادة أولويتها أو رفع جودة الخدمة المُقدمة لها، كما يُمكن أن يُشنَّ هجوم حجب الخدمة أيضًا من خلال تغيير قيمة حقل صنف الخدمة، لجعل رزمة أو مجموعة رزم بيانات تحصل على جودة خدمة أقل من الجودة المتوقعة لها، وقد يسبب هذا تأخيرًا زمنيًّا في وصولها إلى هدفها أو التخلص منها في الوجهة.<ref name="RFC-127">{{استشهاد مختصر|RFC 2474|ص=15|لغة=en}}</ref> |
|||
== بروتوكولات رديفة == |
== بروتوكولات رديفة == |
||
سطر 1٬302: | سطر 640: | ||
| title = بروتوكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت |
| title = بروتوكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت |
||
| name = Internet Control Message Protocol for IPv6 |
| name = Internet Control Message Protocol for IPv6 |
||
| logo = |
|||
| logo size = |
|||
| logo alt = |
|||
| logo caption = |
|||
| صورة = لا |
| صورة = لا |
||
| image size = |
|||
| image alt = |
|||
| caption = |
|||
| abbrrviation = ICMPv6 |
| abbrrviation = ICMPv6 |
||
| purpose = بروتوكول مساعد للإصدار السادس من بروتوكول الإنترنت |
| purpose = بروتوكول مساعد للإصدار السادس من بروتوكول الإنترنت |
||
| developer = [[مجموعة مهندسي |
| developer = [[مجموعة مهندسي الإنترنت]] |
||
| date = ديسمبر 1995 |
| date = ديسمبر 1995 |
||
| based on = [[بروتوكول رسائل التحكم في الإنترنت]] |
| based on = [[بروتوكول رسائل التحكم في الإنترنت]] |
||
| influenced = |
| influenced = |
||
| osilayer = [[طبقة الشبكة]] |
| osilayer = [[طبقة الشبكة]] |
||
| ports = |
|||
| rfcs = RFC 4443<ref name="RFC-21"/> |
| rfcs = RFC 4443<ref name="RFC-21"/> |
||
| hardware = |
|||
| influence = |
|||
| حل محل = لا |
| حل محل = لا |
||
}} |
}} |
||
بروتوكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت {{إنج|Internet Control Message Protocol for IPv6 |
بروتوكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت {{إنج|Internet Control Message Protocol for IPv6 اختصارًا ICMPv6}} هو بروتوكول مساعد للإصدار السادس من بروتوكول الإنترنت وجزءٌ مدمج منه، طُوِّر هذا البروتوكول بالتوازي مع الإصدار السادس من بروتوكول الإنترنت وصدر معياره الأصلي في شهر ديسمبر من العام 1995م ووصف في [[طلب تعليقات|وثيقة طلب التعليقات]] RFC 1885.<ref name="RFC-13"/> |
||
تستعمل العقد التي تُشغِّل الإصدار السادس من بروتوكول الإنترنت بروتوكول رسائل التحكم للتبليغ عن الأخطاء الحاصلة أثناء معالجة رزم البيانات ولأداء وظائف أخرى مرتبطة بطبقة الشبكة مثل تشخيص المُشكلات باستعمال [[بينج (أمر)|أمر التحقق من المسار]]، ويلزم أن يكون |
تستعمل العقد التي تُشغِّل الإصدار السادس من بروتوكول الإنترنت بروتوكول رسائل التحكم للتبليغ عن الأخطاء الحاصلة في أثناء معالجة رزم البيانات ولأداء وظائف أخرى مرتبطة بطبقة الشبكة مثل تشخيص المُشكلات باستعمال [[بينج (أمر)|أمر التحقق من المسار]]، ويلزم أن يكون مدعومًا بشكل كامل في العقد التي تشغل الإصدار السادس من بروتوكول الإنترنت جميعِها.<ref name="RFC-132">{{استشهاد مختصر|1=RFC 4443|ص=3|لغة=en}}</ref> |
||
يُعرِّف البروتوكول ترويسة خاصة به طولها 4 [[بايت]]، تُضاف بعد ترويسة الإصدار السادس. ولهذه الترويسة مُعرِّف مميز هو 58، يلزم أن يُشار إليه في حقل الترويسة التالية في داخل الترويسة التي تسبق ترويسة هذا البروتوكول. بالإضافة لذلك، يُعرِّف المعيار الأصلي للبروتوكول 4 رسائل أخطاء وثلاث رسائل استعلام.<ref name="RFC-133">RFC 1885 |
يُعرِّف البروتوكول ترويسة خاصة به طولها 4 [[بايت]]، تُضاف بعد ترويسة الإصدار السادس. ولهذه الترويسة مُعرِّف مميز هو 58، يلزم أن يُشار إليه في حقل الترويسة التالية في داخل الترويسة التي تسبق ترويسة هذا البروتوكول. بالإضافة لذلك، يُعرِّف المعيار الأصلي للبروتوكول 4 رسائل أخطاء وثلاث رسائل استعلام.<ref name="RFC-133">{{استشهاد مختصر|1=RFC 1885|ص=2|لغة=en}}</ref> ولكن أضيفت العديد من الرسائل لاحقًا لخدمة وظائف مختلفة مثل رسائل التماس الموجه التي أضافها بروتوكول اكتشاف الجيران وغير ذلك.<ref group="Web">{{استشهاد ويب |
||
| مسار أرشيف = https://web.archive.org/web/20200507123528/https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml |
| مسار أرشيف = https://web.archive.org/web/20200507123528/https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml |
||
| تاريخ أرشيف = |
| تاريخ أرشيف = 7 مايو 2020 |
||
| مسار= https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml |
| مسار= https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml |
||
| عنوان= Internet Control Message Protocol version 6 (ICMPv6) Parametersry |
| عنوان= Internet Control Message Protocol version 6 (ICMPv6) Parametersry |
||
سطر 1٬336: | سطر 664: | ||
| تاريخ الوصول= 28 مايو 2020}}</ref> |
| تاريخ الوصول= 28 مايو 2020}}</ref> |
||
في شهر ديسمبر من العام 1998 صدر تحديث جديد للبروتوكول في وثيقة طلب التعليقات RFC 2463،<ref name="RFC-19"/> وبعدها بثمانية سنوات صدرت الوثيقة RFC 4443 وهي المعيار الحالي للبروتوكول وهي تتضمن |
في شهر ديسمبر من العام 1998 صدر تحديث جديد للبروتوكول في وثيقة طلب التعليقات RFC 2463،<ref name="RFC-19"/> وبعدها بثمانية سنوات صدرت الوثيقة RFC 4443 وهي المعيار الحالي للبروتوكول وهي تتضمن تفصيلًا إضافيًّا عن [[ثغرة أمنية (حوسبة)|الثغرات الأمنية]] التي يمكن استعماها لشن هجمات عبر البروتوكول وكيفية الوقاية منها ومجموعة من الاعتبارات اللازمة [[أيانا|لهيئة أرقام الإنترنت المُخصصة]] من أجل تعريف أنواع رسائل جديدة.<ref name="RFC-21"/> |
||
{{تحديد}} |
{{تحديد}} |
||
سطر 1٬354: | سطر 682: | ||
| abbrrviation = NDP |
| abbrrviation = NDP |
||
| purpose = بروتوكول مساعد للإصدار السادس من بروتوكول الإنترنت |
| purpose = بروتوكول مساعد للإصدار السادس من بروتوكول الإنترنت |
||
| developer = [[مجموعة مهندسي |
| developer = [[مجموعة مهندسي الإنترنت]] |
||
| date = أغسطس 1996 |
| date = أغسطس 1996 |
||
| based on = [[بروتوكول رسائل التحكم في الإنترنت]] |
| based on = [[بروتوكول رسائل التحكم في الإنترنت]] |
||
سطر 1٬366: | سطر 694: | ||
}} |
}} |
||
{{مفصلة|بروتوكول اكتشاف الجيران}} |
{{مفصلة|بروتوكول اكتشاف الجيران}} |
||
بروتوكول اكتشاف الجيران {{إنج|Neighbor Discovery Protocol}} هو بروتوكول مساعد للإصدار السادس من بروتوكول الإنترنت، يعمل بين الطبقتين [[طبقة الوصلة|الثانية]] والثالثة |
بروتوكول اكتشاف الجيران {{إنج|Neighbor Discovery Protocol}} هو بروتوكول مساعد للإصدار السادس من بروتوكول الإنترنت، يعمل بين الطبقتين [[طبقة الوصلة|الثانية]] والثالثة وفقًا [[نموذج الربط البيني للأنظمة المفتوحة]]، ويقدم خدمات التعرف على الموجهات والتعرف على الجيران وإعادة التوجيه. طرح المعيار الأصلي للبروتوكول في أغسطس من العام 1996 ووصف في وثيقة طلب التعليقات RFC 1970.<ref name="RFC-22"/> |
||
يُعرِّف هذا البروتوكول 5 رسائل من بروتوكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت هن: رسالة إعادة التوجيه |
يُعرِّف هذا البروتوكول 5 رسائل من بروتوكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت هن: رسالة إعادة التوجيه وزوجين من الرسائل لاكتشاف عناوين الموجهات في الشبكة المحلية، هما رسالة التماس الموجه ورسالة الإعلان عن الموجه، وزوجين لاكتشاف عناوين الجيران، هما رسالة التماس الجار ورسالة الإعلان عن الجار اللتان أدى بهما البروتوكول مع الإصدار السادس وظيفة اقتران العناوين بين الطبقتين الثالثة والثانية، وهي الوظيفة نفسها التي يؤديها [[بروتوكول اقتران العناوين]] مع [[بروتوكول الإنترنت (الإصدار الرابع)|الإصدار الرابع من بروتوكول الإنترنت]].<ref name="RFC-135">{{استشهاد مختصر|RFC 4861|ص=11|لغة=en}}</ref> |
||
طُوِّرت أشكال متنوعة مشتقة من هذا البروتوكول، منها بروتوكول اكتشاف الجيران العكسيّ {{إنج|Inverse Neighbor Discovery Protocol}} الذي يؤدي وظيفة اقتران العناوين العكسية بين الطبقتين الثانية والثالثة والذي وصف في الوثيقة RFC 3122 على أنه توسعة لبروتوكول اكتشاف الجيران،<ref name="RFC-136">{{استشهاد |
طُوِّرت أشكال متنوعة مشتقة من هذا البروتوكول، منها بروتوكول اكتشاف الجيران العكسيّ {{إنج|Inverse Neighbor Discovery Protocol}} الذي يؤدي وظيفة اقتران العناوين العكسية بين الطبقتين الثانية والثالثة والذي وصف في الوثيقة RFC 3122 على أنه توسعة لبروتوكول اكتشاف الجيران،<ref name="RFC-136">{{استشهاد مختصر|RFC 3122|ص=1|لغة=en}}</ref> وأيضًا بروتوكول اكتشاف الجيران الآمن {{إنج|SEcure Neighbor Discovery Protocol اختصارًا SEND}} الذي يُعرِّف آلياتٍ آمنة لتبادل بيانات الشبكة وفق بروتوكول اكتشاف الجيران، وقد وُصِف في وثيقة طلب التعليقات RFC 3971.<ref name="RFC-137">{{استشهاد مختصر|RFC 3971|ص=1|لغة=en}}</ref> |
||
| الأخير= Conta |
|||
| الأول= A. |
|||
| تاريخ= يونيو 2001 |
|||
| مسار أرشيف = https://web.archive.org/web/20191212185124/https://tools.ietf.org/html/rfc3122 |
|||
| مسار= https://tools.ietf.org/html/rfc3122 |
|||
| عنوان= RFC 3122, Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification |
|||
| لغة= en |
|||
| doi = 10.17487/RFC3122 |
|||
|تاريخ أرشيف=2019-12-12}}</ref> وأيضاً بروتوكول اكتشاف الجيران الآمن {{إنج| SEcure Neighbor Discovery Protocol اختصاراً SEND}} الذي يُعرِّف آلياتٍ آمنة لتبادل بيانات الشبكة وفق بروتوكول اكتشاف الجيران، وقد وُصِف في وثيقة طلب التعليقات RFC 3971.<ref name="RFC-137">{{استشهاد ويب |
|||
| الأخير= Arkko |
|||
| الأول= J. |
|||
| الأخير2= Kempf |
|||
| الأول2= J. |
|||
| الأخير3= Zill |
|||
| الأول3= B. |
|||
| الأخير4= Nikander |
|||
| الأول4= P. |
|||
| تاريخ= مارس 2005 |
|||
| مسار أرشيف = https://web.archive.org/web/20200428010800/https://tools.ietf.org/html/rfc3971 |
|||
| مسار= https://tools.ietf.org/html/rfc3971 |
|||
| عنوان= RFC 3971, SEcure Neighbor Discovery (SEND) |
|||
| لغة= en |
|||
| doi = 10.17487/RFC3971 |
|||
|تاريخ أرشيف=2020-04-28}}</ref> |
|||
في ديسمبر من العام 1998م، |
صدر تحديث جديد للمعيار في ديسمبر من العام 1998م، وحملت الوثيقة الاسم الرمزي RFC 2461. ثم صدرت الوثيقة RFC 4861 في شهر سبتمبر من العام 2007م، وهي المعيار الحالي لبروتوكول اكتشاف الجيران.<ref name="RFC-22"/> |
||
{{تحديد}} |
{{تحديد}} |
||
سطر 1٬404: | سطر 708: | ||
| title = بروتوكول اكتشاف مستمعي البث المجموعاتي |
| title = بروتوكول اكتشاف مستمعي البث المجموعاتي |
||
| name = Multicast Listener Discovery |
| name = Multicast Listener Discovery |
||
| logo = |
|||
| logo size = |
|||
| logo alt = |
|||
| logo caption = |
|||
| صورة = لا |
| صورة = لا |
||
| purpose = إدارة مجموعة [[بث متعدد الوجهات|البث المجموعاتي]] في الإصدار السادس من بروتوكول الإنترنت |
|||
| image size = |
|||
| developer = [[مجموعة مهندسي الإنترنت]] |
|||
| image alt = |
|||
| caption = |
|||
| purpose = إدارة مجموعة [[بث متعدد|البث المجموعاتي]] في الإصدار السادس من بروتوكول الإنترنت |
|||
| developer = [[مجموعة مهندسي شبكة الإنترنت]] |
|||
| date = 2004 |
| date = 2004 |
||
| based on = |
|||
| influenced = |
|||
| osilayer = [[طبقة الشبكة]] |
| osilayer = [[طبقة الشبكة]] |
||
| rfcs = RFC 3810<ref name="ietf-35">{{استشهاد مختصر|RFC 3810|ص=1|لغة=en}}</ref> |
|||
| ports = |
|||
| rfcs = RFC 3810<ref name="ietf-35">{{استشهاد ويب |
|||
| مؤلف1 = R. Vida |
|||
| مؤلف2 = B. Cain |
|||
| مؤلف3 = L. Costa |
|||
| تاريخ= يونيو 2004 |
|||
| مسار أرشيف = https://web.archive.org/web/20050217103700/http://www.ietf.org/rfc/rfc3810| مسار= https://www.ietf.org/rfc/rfc3810 |
|||
| عنوان= RFC 3810, Multicast Listener Discovery Version 2 (MLDv2) for IPv6 |
|||
Multicast |
|||
| موقع= The Internet Society |
|||
| لغة= en |
|||
| تاريخ الوصول= 6 مارس 2017| تاريخ أرشيف = 17 فبراير 2005 }}</ref> |
|||
| hardware = |
|||
| حل محل = لا |
| حل محل = لا |
||
}} |
}} |
||
بروتوكول اكتشاف مستمعي البث المجموعاتي {{إنج|Multicast Listener Discovery اختصاراً MLD}} هو [[بروتوكول (اتصالات)|بروتوكول اتصال]] يعمل على مستوى [[طبقة الشبكة|الطبقة الثالثة]] |
بروتوكول اكتشاف مستمعي البث المجموعاتي {{إنج|Multicast Listener Discovery اختصاراً MLD}} هو [[بروتوكول (اتصالات)|بروتوكول اتصال]] يعمل على مستوى [[طبقة الشبكة|الطبقة الثالثة]] وفقًا لنموذج الربط البيني للأنظمة المفتوحة، يدير المجموعات الخاصة بالبث المجموعاتي لرزم [[العنونة في الإصدار السادس من بروتوكول الإنترنت|الإصدار السادس من بروتوكول الإنترنت]]، وبشكلٍ خاص اكتشاف أعضاء المجموعات في [[شبكة محلية|الشبكات المحلية]] وتحديد أي المجموعات التي يهتمون باستقبال رزمها.<ref name="Book-23">{{استشهاد مختصر|Fall|2012|ص=451-453|لغة=en}}</ref> |
||
يُقدّم البروتوكول |
يُقدّم البروتوكول مفهومًا خاصًّا بالإصدار السادس هو مفهوم مُستمع البث المجموعاتي {{إنج|Multicast Listener}}، وهو وفقًا للتعريف، [[عقدة (شبكات)|عقدة]] ترغب في استقبال رزم البث المجموعاتي. إذا استضاف المستمع عنوان مجموعة ما، أصبح عضوًا فيها، وبات يهتم باستقبال رزمها. يمكن أن ينضم المستمع إلى أكثر من مجموعة في الوقت نفسه. ومن هنا حصل البروتوكول على اسمه، فالبروتوكول يساعد تجهيزات الطبقة الثالثة المُتصلة مع الشبكة المحليّة على اكتشاف وجود المُستمعين فيها. يُوصف البروتوكول أيضًا بأنه غير متناظر {{إنج|Asymmertic}}، لأنه يسلك سلوكًا مختلفًا عند تعامله مع المستمعين عن ذلك الذي يتبعه مع تجهيزات الطبقة الثالثة، مثل [[موجه (شبكات)|المُوجِّهات]].<ref name = "Book-98">{{استشهاد مختصر|1=Rosen|2=2014|ص=230|لغة=en}}</ref> |
||
|مؤلف = Rami Rosen |
|||
|عنوان= Linux Kernel Networking: Implementation and Theory (Expert's Voice in Open Source) |
|||
|صفحة=230 |
|||
|سنة=2013 |
|||
|ناشر= Apress |
|||
|الرقم المعياري=143026196X |
|||
|لغة= en |
|||
}}</ref> |
|||
يوجد إصداران لبروتوكول اكتشاف مستمعي الإنترنت، الإصدار الأول منه موصوف في [[طلب تعليقات|وثيقة طلب التعليقات]] RFC 2710 <ref name="RFC-130">{{استشهاد مختصر|RFC 2710|ص=1|لغة=en}}</ref> وقد طُوّر في العام 1999م، وهو مُكافئ للإصدار الثاني من بروتوكول إدارة مجموعة الإنترنت (IGMPv2) من حيث الوظيفة، أمّا الإصدار الثاني فطوّر في العام 2004م، وهو موصوف بالوثيقة RFC 3810<ref name="ietf-35"/> ويُكافئ الإصدار الثالث من بروتوكول إدارة مجموعة الإنترنت (IGMPv3)، ويدعم ميزات إضافية مثل {{وإو|البث المجموعاتي محدد المصدر|Source-specific multicast|en|البث المجموعاتي مُحدد المصدر}}.<ref name="RFC-134">{{استشهاد مختصر|RFC 4604|ص=1|لغة=en}}</ref> |
|||
| مؤلف1 = S. Deering |
|||
| مؤلف2 = W. Fenner |
|||
| مؤلف3 = B. Haberman |
|||
| تاريخ= أوكتوبر 1999 |
|||
| مسار أرشيف = https://web.archive.org/web/20200325105209/https://www.ietf.org/rfc/rfc2710 |
|||
| مسار= https://www.ietf.org/rfc/rfc2710 |
|||
| عنوان= RFC 2710, Multicast Listener Discovery (MLD) for IPv6 Multicast |
|||
| موقع= The Internet Society |
|||
| لغة= en |
|||
| تاريخ الوصول= 6 مارس 2017 |
|||
|تاريخ أرشيف=2020-03-25}}</ref> وقد طُوّر في العام 1999م، وهو مُكافئ للإصدار الثاني من بروتوكول إدارة مجموعة الإنترنت (IGMPv2) من حيث الوظيفة، أمّا الإصدار الثاني فطوّر في العام 2004م، وهو موصوف بالوثيقة RFC 3810<ref name="RFC-131">{{{استشهاد ويب |
|||
| مؤلف1 = R. Vida |
|||
| مؤلف2 = B. Cain |
|||
| مؤلف3 = L. Costa |
|||
| تاريخ= يونيو 2004 |
|||
| مسار أرشيف = https://web.archive.org/web/20050217103700/http://www.ietf.org/rfc/rfc3810 |
|||
| مسار= https://www.ietf.org/rfc/rfc3810 |
|||
| عنوان= RFC 3810, Multicast Listener Discovery Version 2 (MLDv2) for IPv6 Multicast |
|||
| موقع= The Internet Society |
|||
| لغة= en |
|||
| تاريخ الوصول= 6 مارس 2017 |
|||
| تاريخ أرشيف = 17 فبراير 2005 }}</ref> ويُكافئ الإصدار الثالث من بروتوكول إدارة مجموعة الإنترنت (IGMPv3)، ويدعم ميزات إضافية مثل {{وإو|البث المجموعاتي محدد المصدر|Source-specific multicast|en|البث المجموعاتي مُحدد المصدر}}.<ref name="RFC-134">{{استشهاد ويب |
|||
| مؤلف1 = H. Holbrook |
|||
| مؤلف2 = B. Cain |
|||
| مؤلف3 = B. Haberman |
|||
| تاريخ= أغسطس 2006 |
|||
| مسار أرشيف = https://web.archive.org/web/20120811005752/http://www.ietf.org/rfc/rfc4604 |
|||
| مسار= https://www.ietf.org/rfc/rfc4604 |
|||
| عنوان= RFC 4604, Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast |
|||
| موقع= The Internet Society |
|||
| لغة= en |
|||
| تاريخ الوصول= 6 مارس 2017|تاريخ أرشيف=2012-08-11}}</ref> |
|||
{{تحديد}} |
{{تحديد}} |
||
== هوامش == |
== هوامش == |
||
<div class="reflist4" style="height: 250px; overflow: auto; padding: 3px" > |
<div class="reflist4" style="height: 250px; overflow: auto; padding: 3px" > |
||
{{هامش|1}}. لا يُلزم المعيار منفذي البروتوكول اتباعَ الترتيب |
{{هامش|1}}. لا يُلزم المعيار منفذي البروتوكول اتباعَ الترتيب التالي اتباعًا إلزاميًّا، ولكنه يستحسن ذلك.<ref name="RFC-35"/> |
||
{{هامش|2}}. |
{{هامش|2}}. في ما يخص محتويات ترويسة خيارات الوجهة، سواء كانت الوجهة الأولى أو وجهات البينية على مسار الرزمة، فهي تخضع لهذه القاعدة أيضًا. فإذا أُرسلت الرزمة عبر مسار محدد نحو وجهتها النهائية، فإن عناوين الوجهات البينية المتوقعة على طول المسار تكون موجودة في ترويسة التوجيه فيها، وتكون قيمة حقل عنوان الوجهة في ترويسة البروتوكول هي عنوان الوجهة الأولى. وعندما تصل الرزمة إلى الوجهة الأولى، فإن البروتوكول يُغيِّر قيمة عنوان الوجهة، ويضع بدلًا منه العنوان التالي الموجود في ترويسة التوجيه. عمليًّا، لم تُعالج ترويسات التوسعة في الرزمة حتى بلغت الرزمة وجهتها، وهذه الوجهة مُحددة بعنوان الوجهة في ترويسة البروتوكول. |
||
{{هامش|3}}. في النوع ذو القيمة 0، يستطيع المضيف المصدر أن يحدد عناوين العقد التي ستمر فيها الرزمة بالترتيب، وسبب هذا |
{{هامش|3}}. في النوع ذو القيمة 0، يستطيع المضيف المصدر أن يحدد عناوين العقد التي ستمر فيها الرزمة بالترتيب، وسبب هذا إشكالًا أمنيًّا لأنه يسمح بإدراج العنوان نفسه أكثر من مرة في الترويسة نفسها، ويسبب هذا إعادة توجيه الرزمة نحو نفس العقدة أكثر من مرة خلال مسارها.<ref name="Book-7"/> |
||
{{هامش|4}}. [[قطاع شبكي|القطاع الشبكي]] هو اتصال كهربائي مشترك بين منافذ الشبكة.<ref name = "JOU-1">{{استشهاد |
{{هامش|4}}. [[قطاع شبكي|القطاع الشبكي]] هو اتصال كهربائي مشترك بين منافذ الشبكة.<ref name = "JOU-1">{{استشهاد مختصر|1=IEEE 802.3|ص=35|لغة=en}}</ref> |
||
|صحيفة = IEEE Std 802.3-2008 (Revision of IEEE Std 802.3-2005) |
|||
|عنوان= 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 |
|||
|المجلد= |
|||
|العدد = |
|||
|سنة= 2008 |
|||
|شهر= ديسمبر |
|||
|صفحة= 35 |
|||
| ناشر = IEEE |
|||
| doi = 10.1109/IEEESTD.2008.4726971 |
|||
| مسار = https://ieeexplore.ieee.org/document/4726971 |
|||
|مسار أرشيف= https://web.archive.org/web/20180623111432/https://ieeexplore.ieee.org/document/4726971/|تاريخ أرشيف=2018-06-23}}</ref> |
|||
{{هامش|5}}. يختلف تفسير معنى كلمة |
{{هامش|5}}. يختلف تفسير معنى كلمة «أقرب» باختلاف [[بروتوكول توجيه|بروتوكول التوجيه]] المُستعمل، فلكل بروتوكول توجيه آلية محددة لقياس وزن المسار، قد تعتمد على عدد القفزات للوجهة، أو على مُعدل النقل في الوصلات أو غير ذلك، ويتحدد المنفذ الأقرب حسبَ هذه الآلية. |
||
{{هامش|6}}. يلزم أن تُكتب [[كتابة لاتينية|الحروف اللاتينية]] بالحالة الصغيرة لا الكبيرة، أي a لا A.<ref name="RFC-65">RFC 5952 |
{{هامش|6}}. يلزم أن تُكتب [[كتابة لاتينية|الحروف اللاتينية]] بالحالة الصغيرة لا الكبيرة، أي a لا A.<ref name="RFC-65">{{استشهاد مختصر|RFC 5952|ص=10|لغة=en}}</ref> |
||
{{هامش|7}}. لا تستخدم محددات البروتوكول كلمة رباعية، ولكن هذه الكلمة شائعة لوصف هذا المفهوم. |
{{هامش|7}}. لا تستخدم محددات البروتوكول كلمة رباعية، ولكن هذه الكلمة شائعة لوصف هذا المفهوم. |
||
سطر 1٬509: | سطر 741: | ||
{{هامش|8}}. بسبب كون قيمة بت المحلية ثابتة دائماً على القيمة 1، لعدم وجود استخدام آخر لها حتى الآن، فإن بعض المراجع تشير لبادئة هذا الفضاء بالشكل {{عنوان بروتوكول إنترنت في النسق|fd::/8}} بدلاً من {{عنوان بروتوكول إنترنت في النسق|fc::/7}}، وهذا خطأ شائع لا يجوز، لأن المعيار الرسمي يُشير إلى إمكانية تطوير لاحقة لاستخدامات أخرى لهذا العنوان تكون قيمة بت محلية فيها مساويةً للصفر.<ref name="RFC-99" /> |
{{هامش|8}}. بسبب كون قيمة بت المحلية ثابتة دائماً على القيمة 1، لعدم وجود استخدام آخر لها حتى الآن، فإن بعض المراجع تشير لبادئة هذا الفضاء بالشكل {{عنوان بروتوكول إنترنت في النسق|fd::/8}} بدلاً من {{عنوان بروتوكول إنترنت في النسق|fc::/7}}، وهذا خطأ شائع لا يجوز، لأن المعيار الرسمي يُشير إلى إمكانية تطوير لاحقة لاستخدامات أخرى لهذا العنوان تكون قيمة بت محلية فيها مساويةً للصفر.<ref name="RFC-99" /> |
||
{{هامش|9}}. حُرر هذا الفضاء في شهر مارس من العام 2014، ولم يعد |
{{هامش|9}}. حُرر هذا الفضاء في شهر مارس من العام 2014، ولم يعد محجوزًا.<ref name="Web-6" group="Web"/> |
||
{{هامش|10}}. للتحصيص {{إنج|Allocation}} وللتخصيص {{إنج|Assignment}} معنيان متمايزان في نظام سجلات عناوين الأنترنت. يُشير الأول، أي التحصيص، إلى تفويض منظمةٍ بالإشراف على فضاءٍ جزئيٍّ من فضاء بروتوكول الإنترنت مع توقعٍ بقيام هذه المنظمة [[تجزئة الشبكة|بتجزئة]] الفضاء وتفويض الأفضية الجزئية الناتجة إلى منظمات أخرى. أمّا الثاني، أي التخصيص، فهو يستعمل عند منح الفضاء إلى الجهات التي تستخدمه مباشرة في عنونة مجموعة من المضيفين.<ref name="RFC-107">{{استشهاد |
{{هامش|10}}. للتحصيص {{إنج|Allocation}} وللتخصيص {{إنج|Assignment}} معنيان متمايزان في نظام سجلات عناوين الأنترنت. يُشير الأول، أي التحصيص، إلى تفويض منظمةٍ بالإشراف على فضاءٍ جزئيٍّ من فضاء بروتوكول الإنترنت مع توقعٍ بقيام هذه المنظمة [[تجزئة الشبكة|بتجزئة]] الفضاء وتفويض الأفضية الجزئية الناتجة إلى منظمات أخرى. أمّا الثاني، أي التخصيص، فهو يستعمل عند منح الفضاء إلى الجهات التي تستخدمه مباشرة في عنونة مجموعة من المضيفين.<ref name="RFC-107">{{استشهاد مختصر|RFC 2050|ص=4|لغة=en}}</ref> |
||
| الأخير= Hubbard |
|||
| الأول= K. |
|||
| الأخير2= Kosters |
|||
| الأول2= M. |
|||
| الأخير3= Conrad |
|||
| الأول3= D. |
|||
| الأخير4= Karrenberg |
|||
| الأول4= D. |
|||
| الأخير5= Postel |
|||
| الأول5= J. |
|||
| تاريخ= نوفمبر 1996 |
|||
| مسار= https://tools.ietf.org/html/rfc2050 |
|||
| عنوان= RFC 2050, INTERNET REGISTRY IP ALLOCATION GUIDELINES |
|||
| موقع= The Internet Society |
|||
| لغة= en |
|||
| صفحة = 4 |
|||
| doi = 10.17487/RFC2050 |
|||
| تاريخ الوصول= 22 يناير 2020 |
|||
| مسار أرشيف = https://web.archive.org/web/20191211133106/https://tools.ietf.org/html/rfc2050 |
|||
| تاريخ أرشيف = 11 ديسمبر 2019 }}</ref> |
|||
{{هامش|11}}. يُستثنى البت رقم (0) من المرتبة الستة عشرية الأولى، ولذلك فحدود نهاية معرّف الشبكة الجزئية الخاصة بها تضمّ البتات ذات الفهارس {1,2} فقط، والسبب في ذلك أن استعماله يعني بادئة شبكة بطول (0) بت، وهي حالة مستحيلة. |
{{هامش|11}}. يُستثنى البت رقم (0) من المرتبة الستة عشرية الأولى، ولذلك فحدود نهاية معرّف الشبكة الجزئية الخاصة بها تضمّ البتات ذات الفهارس {1,2} فقط، والسبب في ذلك أن استعماله يعني بادئة شبكة بطول (0) بت، وهي حالة مستحيلة. |
||
{{هامش|12}}. في هذا السياق، تُستثنى ترويسة |
{{هامش|12}}. في هذا السياق، تُستثنى ترويسة تأمين الحمولة بالتغليف وتعامل معاملة ترويسة الطبقات العليا مع أنها من أنها ترويسة توسعة للإصدار السادس من البروتوكول.<ref name="RFC-112"/> |
||
</div> |
</div> |
||
سطر 1٬544: | سطر 756: | ||
== المراجع == |
== المراجع == |
||
=== فهرس المراجع === |
|||
;فهرس المنشورات العربية |
|||
<div class="reflist4" style="height: 250px; overflow: auto; padding: 3px" > |
|||
{{بداية المراجع}} |
|||
{{مراجع|2|محاذاة=نعم}} |
|||
{{مراجع|مجموعة="ar"}} |
|||
</div> |
|||
{{نهاية المراجع}} |
|||
;فهرس المنشورات الأجنبية |
|||
'''المعلومات الكاملة للمراجع المُستشهد بها أكثر من مرة''' |
|||
{{بداية المراجع}} |
|||
{{مراجع|محاذاة=نعم}} |
|||
''الكتب <small>(مرتبة أبجدياً بحسب العنوان)</small>'' |
|||
{{نهاية المراجع}} |
|||
;فهرس مواقع الويب |
|||
<div class="mw-content-ltr"> |
|||
{{بداية المراجع|محاذاة=نعم}} |
|||
{{مراجع|مجموعة="Web"}} |
|||
* {{استشهاد بكتاب |
|||
{{نهاية المراجع}} |
|||
|مؤلف1= Wendell Odom |
|||
=== معلومات المراجع المُفصَّلة === |
|||
|عنوان= Cisco CCENT/CCNA ICND1 100-101 Official Cert Guide |
|||
;الكتب <small>(مرتبة تصاعديًّا حسب تاريخ النشر)</small> |
|||
|طبعة= الأكاديمية |
|||
<u>الإنجليزية:</u> |
|||
|سنة=2013 |
|||
{{بداية المراجع|2|محاذاة=نعم}} |
|||
|ناشر= Pearson Education, Inc. |
|||
* {{استشهاد بويكي بيانات|Q115917529|مرجع=Dyson1999}} |
|||
|الرقم المعياري= 1587144859 |
|||
* {{استشهاد بويكي بيانات|Q118316084|مرجع=Javvin2005}} |
|||
|لغة= en |
|||
* {{استشهاد بويكي بيانات|Q115917346|مرجع=Kozierok2005}} |
|||
}} |
|||
* {{استشهاد |
* {{استشهاد بويكي بيانات|Q119841470|مرجع=Rosen2014}} |
||
* {{استشهاد بويكي بيانات|Q115922106|مرجع=Fall2012}} |
|||
|مؤلف1= Kevin R.Fall |
|||
* {{استشهاد بويكي بيانات|Q115919723|مرجع=Odom2013}} |
|||
|مؤلف2= W.Richard Stevens |
|||
{{نهاية المراجع}} |
|||
|عنوان= TCP/IP Illustrated Volume 1 |
|||
<u>العربية:</u> |
|||
|طبعة= الثانية |
|||
{{بداية المراجع}} |
|||
|صفحة= |
|||
* {{استشهاد بويكي بيانات|Q111284802|مرجع=بكني2022}} |
|||
|مسار= https://web.archive.org/web/20171120064332/http://www.r-5.org/files/books/computers/internals/net/Richard_Stevens-TCP-IP_Illustrated-EN.pdf |
|||
{{نهاية المراجع}} |
|||
|سنة=2012 |
|||
;وثائق طلب التعليقات <small>(مرتبة تصاعديًّا حسب رقم الوثيقة)</small> |
|||
|ناشر= Pearson Education, Inc |
|||
{{بداية المراجع|2|محاذاة=نعم}} |
|||
|الرقم المعياري= 0321336313 |
|||
* {{استشهاد بويكي بيانات|Q47467078|مرجع=RFC 791}} |
|||
|لغة= en |
|||
* {{استشهاد بويكي بيانات|Q47460092|مرجع=RFC 1112}} |
|||
}} |
|||
* {{استشهاد بويكي بيانات|Q47468405|مرجع=RFC 1338}} |
|||
</div> |
|||
* {{استشهاد بويكي بيانات|Q47314090|مرجع=RFC 1518}} |
|||
''وثائق طلب التعليقات <small>(مرتبة بحسب رقم الوثيقة)</small>'' |
|||
* {{استشهاد بويكي بيانات|Q47199620|مرجع=RFC 1519}} |
|||
<div class="mw-content-ltr" style="height: 250px; overflow: auto; padding: 1px"> |
|||
* {{استشهاد |
* {{استشهاد بويكي بيانات|Q47470454|مرجع=RFC 1550}} |
||
* {{استشهاد بويكي بيانات|Q47164409|مرجع=RFC 1631}} |
|||
| الأخير= Postel |
|||
* {{استشهاد بويكي بيانات|Q47457995|مرجع=RFC 1752}} |
|||
| الأول= J. |
|||
* {{استشهاد بويكي بيانات|Q47472593|مرجع=RFC 1883}} |
|||
| تاريخ= سبتمبر 1981 |
|||
* {{استشهاد بويكي بيانات|Q47461872|مرجع=RFC 1884}} |
|||
| مسار أرشيف = https://web.archive.org/web/20200212125448/https://tools.ietf.org/html/rfc791 |
|||
* {{استشهاد بويكي بيانات|Q47468348|مرجع=RFC 1885}} |
|||
| مسار= https://tools.ietf.org/html/rfc791 |
|||
* {{استشهاد بويكي بيانات|Q47474638|مرجع=RFC 1970}} |
|||
| عنوان= RFC 791, Internet Protocol, DARPA Internet Program Protocol Specification |
|||
* {{استشهاد بويكي بيانات|Q47471157|مرجع=RFC 1971}} |
|||
| موقع=The Internet Society |
|||
* {{استشهاد بويكي بيانات|Q47483471|مرجع=RFC 2050}} |
|||
| لغة= en |
|||
* {{استشهاد بويكي بيانات|Q47467387|مرجع=RFC 2460}} |
|||
| doi = 10.17487/RFC0791 |
|||
* {{استشهاد بويكي بيانات|Q47466167|مرجع=RFC 2461}} |
|||
|تاريخ أرشيف=2020-02-12}} |
|||
* {{استشهاد |
* {{استشهاد بويكي بيانات|Q47469328|مرجع=RFC 2462}} |
||
* {{استشهاد بويكي بيانات|Q47455723|مرجع=RFC 2463}} |
|||
| الأخير= Rekhter |
|||
* {{استشهاد بويكي بيانات|Q47470529|مرجع=RFC 2474}} |
|||
| الأول= Y. |
|||
* {{استشهاد بويكي بيانات|Q47468506|مرجع=RFC 2675}} |
|||
| الأخير2= Li |
|||
* {{استشهاد بويكي بيانات|Q47464272|مرجع=RFC 2710}} |
|||
| الأول2= T. |
|||
* {{استشهاد بويكي بيانات|Q47466415|مرجع=RFC 2928}} |
|||
| تاريخ= سبتمبر 1993 |
|||
* {{استشهاد بويكي بيانات|Q47477469|مرجع=RFC 3122}} |
|||
| مسار أرشيف = https://web.archive.org/web/20200109062835/https://tools.ietf.org/html/rfc1518 |
|||
* {{استشهاد بويكي بيانات|Q47477513|مرجع=RFC 3056}} |
|||
| مسار= https://tools.ietf.org/html/rfc1518 |
|||
* {{استشهاد بويكي بيانات|Q47472870|مرجع=RFC 3306}} |
|||
| عنوان= RFC 1518, An Architecture for IP Address Allocation with CIDR |
|||
* {{استشهاد بويكي بيانات|Q47467351|مرجع=RFC 3810}} |
|||
| لغة= en |
|||
* {{استشهاد بويكي بيانات|Q47468196|مرجع=RFC 3849}} |
|||
| doi = 10.17487/RFC1518 |
|||
* {{استشهاد بويكي بيانات|Q47322494|مرجع=RFC 3879}} |
|||
| تاريخ الوصول= 15 سبتمبر 2019 |
|||
* {{استشهاد بويكي بيانات|Q47476136|مرجع=RFC 3956}} |
|||
|تاريخ أرشيف=2020-01-09}} |
|||
* {{استشهاد |
* {{استشهاد بويكي بيانات|Q47312783|مرجع=RFC 3971}} |
||
* {{استشهاد بويكي بيانات|Q47481039|مرجع=RFC 4038}} |
|||
| الأخير= Bradner |
|||
* {{استشهاد بويكي بيانات|Q47470884|مرجع=RFC 4291}} |
|||
| الأول= S. |
|||
* {{استشهاد بويكي بيانات|Q47470421|مرجع=RFC 4193}} |
|||
| الأخير2= Mankin |
|||
* {{استشهاد بويكي بيانات|Q47469832|مرجع=RFC 4302}} |
|||
| الأول2= A. |
|||
* {{استشهاد بويكي بيانات|Q47468417|مرجع=RFC 4303}} |
|||
| تاريخ= يناير 1995 |
|||
* {{استشهاد بويكي بيانات|Q47455351|مرجع=RFC 4380}} |
|||
| مسار أرشيف = https://web.archive.org/web/20200502085747/https://tools.ietf.org/html/rfc1752 |
|||
* {{استشهاد بويكي بيانات|Q47461464|مرجع=RFC 4604}} |
|||
| مسار= https://tools.ietf.org/html/rfc1752 |
|||
* {{استشهاد بويكي بيانات|Q47485207|مرجع=RFC 4632}} |
|||
| عنوان= RFC 1752, The Recommendation for the IP Next Generation Protocol |
|||
* {{استشهاد بويكي بيانات|Q47468599|مرجع=RFC 4843}} |
|||
| لغة= en |
|||
* {{استشهاد بويكي بيانات|Q47465975|مرجع=RFC 4861}} |
|||
| doi = 10.17487/RFC1752 |
|||
* {{استشهاد بويكي بيانات|Q47483181|مرجع=RFC 4862}} |
|||
|تاريخ أرشيف=2020-05-02}} |
|||
* {{استشهاد |
* {{استشهاد بويكي بيانات|Q47322771|مرجع=RFC 5095}} |
||
* {{استشهاد بويكي بيانات|Q47320263|مرجع=RFC 5180}} |
|||
| الأخير= Conta |
|||
* {{استشهاد بويكي بيانات|Q47483158|مرجع=RFC 5722}} |
|||
| الأول= A. |
|||
* {{استشهاد بويكي بيانات|Q47462322|مرجع=RFC 5952}} |
|||
| الأخير2= Deering |
|||
* {{استشهاد بويكي بيانات|Q47472726|مرجع=RFC 6275}} |
|||
| الأول2= S. |
|||
* {{استشهاد بويكي بيانات|Q47461703|مرجع=RFC 6437}} |
|||
| تاريخ= ديسمبر 1995 |
|||
* {{استشهاد بويكي بيانات|Q47471511|مرجع=RFC 6052}} |
|||
| مسار أرشيف = https://web.archive.org/web/20200125201738/https://tools.ietf.org/html/rfc1885 |
|||
* {{استشهاد بويكي بيانات|Q47471990|مرجع=RFC 6666}} |
|||
| مسار= https://tools.ietf.org/html/rfc1885 |
|||
* {{استشهاد بويكي بيانات|Q47462480|مرجع=RFC 6890}} |
|||
| عنوان= RFC 1885, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification |
|||
* {{استشهاد بويكي بيانات|Q47484143|مرجع=RFC 6946}} |
|||
| لغة= en |
|||
* {{استشهاد بويكي بيانات|Q47463802|مرجع=RFC 7020}} |
|||
| doi = 10.17487/RFC1885 |
|||
* {{استشهاد بويكي بيانات|Q47470898|مرجع=RFC 7217}} |
|||
|تاريخ أرشيف=2020-01-25}} |
|||
* {{استشهاد |
* {{استشهاد بويكي بيانات|Q47483506|مرجع=RFC 7343}} |
||
* {{استشهاد بويكي بيانات|Q47301999|مرجع=RFC 7346}} |
|||
| الأخير= Deering |
|||
* {{استشهاد بويكي بيانات|Q47207470|مرجع=RFC 7371}} |
|||
| الأول= S. |
|||
* {{استشهاد بويكي بيانات|Q47455650|مرجع=RFC 7401}} |
|||
| الأخير2= Hinden |
|||
* {{استشهاد بويكي بيانات|Q47466972|مرجع=RFC 7450}} |
|||
| الأول2= T. |
|||
* {{استشهاد بويكي بيانات|Q47246249|مرجع=RFC 7535}} |
|||
| تاريخ= ديسمبر 1998 |
|||
* {{استشهاد بويكي بيانات|Q47471706|مرجع=RFC 7723}} |
|||
| مسار أرشيف = https://web.archive.org/web/20200507010539/https://tools.ietf.org/html/rfc2460 |
|||
* {{استشهاد بويكي بيانات|Q47476057|مرجع=RFC 7739}} |
|||
| مسار= https://tools.ietf.org/html/rfc2460 |
|||
* {{استشهاد بويكي بيانات|Q47201872|مرجع=RFC 8155}} |
|||
| عنوان= RFC 2460, Internet Protocol, Version 6 (IPv6) Specification |
|||
* {{استشهاد بويكي بيانات|Q47476951|مرجع=RFC 8200}} |
|||
| لغة= en |
|||
* {{استشهاد بويكي بيانات|Q47456249|مرجع=RFC 8201}} |
|||
| doi = 10.17487/RFC2460 |
|||
{{نهاية المراجع}} |
|||
|تاريخ أرشيف=2020-05-07}} |
|||
;معايير تقانة <small>(مرتبة تصاعديًّا حسب تاريخ النشر)</small> |
|||
* {{استشهاد ويب |
|||
{{بداية المراجع|محاذاة=نعم}} |
|||
| الأخير= Nichols |
|||
* {{استشهاد بويكي بيانات|Q117948716|مرجع=IEEE 802.3}} |
|||
| الأول= K. |
|||
* {{استشهاد بويكي بيانات|Q118316116|مرجع=Guidelines2017}} |
|||
| الأخير2= Blake |
|||
{{نهاية المراجع}} |
|||
| الأول2= S. |
|||
| الأخير3= Baker |
|||
| الأول3= F. |
|||
| الأخير4= Black |
|||
| الأول4= D. |
|||
| تاريخ= ديسمبر 2017 |
|||
| مسار أرشيف = https://web.archive.org/web/20200507010543/https://tools.ietf.org/html/rfc2474 |
|||
| مسار= https://tools.ietf.org/html/rfc2474 |
|||
| عنوان= RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers |
|||
| لغة= en |
|||
| doi = 10.17487/RFC2474 |
|||
|تاريخ أرشيف=2020-05-07}} |
|||
* {{استشهاد ويب |
|||
| الأخير= Haberman |
|||
| الأول= B. |
|||
| الأخير2= Thaler |
|||
| الأول2= D. |
|||
| تاريخ= أغسطس 2002 |
|||
| مسار أرشيف = https://web.archive.org/web/20200507010555/https://tools.ietf.org/html/rfc3306 |
|||
| مسار= https://tools.ietf.org/html/rfc3306 |
|||
| عنوان= RFC 3306, Unicast-Prefix-based IPv6 Multicast Addresses |
|||
| لغة= en |
|||
| doi = 10.17487/RFC3306 |
|||
|تاريخ أرشيف=2020-05-07| تاريخ الوصول = 25 مايو 2020 |
|||
}} |
|||
* {{استشهاد ويب |
|||
| الأخير= Hinden |
|||
| الأول= R. |
|||
| الأخير2= Deering |
|||
| الأول2= S. |
|||
| تاريخ= فبراير 2006 |
|||
| مسار أرشيف = https://web.archive.org/web/20200513020407/https://tools.ietf.org/html/rfc4291 |
|||
| مسار= https://tools.ietf.org/html/rfc4291 |
|||
| عنوان= RFC 4291, IP Version 6 Addressing Architecture |
|||
| لغة= en |
|||
| doi = 10.17487/RFC4291 |
|||
|تاريخ أرشيف=2020-05-13}} |
|||
* {{استشهاد ويب |
|||
| الأخير= Hinden |
|||
| الأول= R. |
|||
| الأخير2= Haberman |
|||
| الأول2= B. |
|||
| تاريخ= أكتوبر 2005 |
|||
| مسار أرشيف = https://web.archive.org/web/20200507010551/https://tools.ietf.org/html/rfc4193 |
|||
| مسار= https://tools.ietf.org/html/rfc4193 |
|||
| عنوان= RFC 4193, Unique Local IPv6 Unicast Addresses |
|||
| لغة= en |
|||
| doi = 10.17487/RFC4193 |
|||
|تاريخ أرشيف=2020-05-07}} |
|||
* {{استشهاد ويب |
|||
|الأخير= Kent |
|||
|الأول= S. |
|||
| تاريخ= ديسمبر 2005 |
|||
| مسار أرشيف = https://web.archive.org/web/20200311155131/https://tools.ietf.org/html/rfc4302 |
|||
| مسار= https://tools.ietf.org/html/rfc4302 |
|||
| عنوان= RFC 4302, IP Authentication Header |
|||
| موقع=The Internet Society |
|||
| لغة= en |
|||
|doi= 10.17487/RFC4302 |
|||
| تاريخ الوصول= 23 مايو 2020 |
|||
|تاريخ أرشيف=2020-03-11}} |
|||
* {{استشهاد ويب |
|||
|الأخير= Kent |
|||
|الأول= S. |
|||
| تاريخ= ديسمبر 2005 |
|||
| مسار أرشيف = https://web.archive.org/web/20200428211409/https://tools.ietf.org/html/rfc4303 |
|||
| مسار= https://tools.ietf.org/html/rfc4303 |
|||
| عنوان= RFC 4303, IP Encapsulating Security Payload (ESP) |
|||
| موقع=The Internet Society |
|||
| صفحة = 3 |
|||
| لغة= en |
|||
|doi= 10.17487/RFC4303 |
|||
| تاريخ الوصول= 23 مايو 2020 |
|||
|تاريخ أرشيف=2020-04-28}} |
|||
* {{استشهاد ويب |
|||
|الأخير= Fuller |
|||
|الأول= V. |
|||
|الأخير2= Li |
|||
|الأول2= T. |
|||
| تاريخ= أغسطس 2006 |
|||
| مسار أرشيف = https://web.archive.org/web/20200216072557/https://tools.ietf.org/html/rfc4632 |
|||
| مسار= https://tools.ietf.org/html/rfc4632 |
|||
| عنوان= RFC 4632, Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan |
|||
| موقع=The Internet Society |
|||
| لغة= en |
|||
|doi= 10.17487/RFC4632 |
|||
|تاريخ أرشيف=2020-02-16}} |
|||
* {{استشهاد ويب |
|||
| الأخير= Narten |
|||
| الأول= T. |
|||
| الأخير2= Nordmark |
|||
| الأول2= E. |
|||
| الأخير3= Simpson |
|||
| الأول3= W. |
|||
| الأخير4= Soliman |
|||
| الأول4= H. |
|||
| تاريخ= سبتمبر 2007 |
|||
| مسار أرشيف = https://web.archive.org/web/20200510160202/https://tools.ietf.org/html/rfc4861 |
|||
| مسار= https://tools.ietf.org/html/rfc4861 |
|||
| عنوان= RFC 4861, Neighbor Discovery for IP version 6 (IPv6) |
|||
| لغة= en |
|||
| doi = 10.17487/RFC4861 |
|||
|تاريخ أرشيف=2020-05-10}} |
|||
* {{استشهاد ويب |
|||
| الأخير= Thomson |
|||
| الأول= S. |
|||
| الأخير2= Narten |
|||
| الأول2= T. |
|||
| الأخير3= Jinmei |
|||
| الأول3= T. |
|||
| تاريخ= سبتمبر 2007 |
|||
| مسار أرشيف = https://web.archive.org/web/20200507010535/https://tools.ietf.org/html/rfc4862 |
|||
| مسار= https://tools.ietf.org/html/rfc4862 |
|||
| عنوان= RFC 4862, IPv6 Stateless Address Autoconfiguration |
|||
| لغة= en |
|||
| doi = 10.17487/RFC4862 |
|||
|تاريخ أرشيف=2020-05-07}} |
|||
* {{استشهاد ويب |
|||
| الأخير= Kawamura |
|||
| الأول= S. |
|||
| الأخير2= Kawashima |
|||
| الأول2= M. |
|||
| تاريخ= أغسطس 2010 |
|||
| مسار أرشيف = https://web.archive.org/web/20200512053700/https://tools.ietf.org/html/rfc5952 |
|||
| مسار= https://tools.ietf.org/html/rfc5952 |
|||
| عنوان= RFC 5952, A Recommendation for IPv6 Address Text Representation |
|||
| موقع= The Internet Society |
|||
| لغة= en |
|||
| doi = 10.17487/RFC5952 |
|||
|تاريخ أرشيف=2020-05-12}} |
|||
* {{استشهاد ويب |
|||
| الأخير= Amante |
|||
| الأول= S. |
|||
| الأخير2= Carpenter |
|||
| الأول2= B. |
|||
| الأخير3= Jiang |
|||
| الأول3= S. |
|||
| الأخير4= Rajahalme |
|||
| الأول4= J. |
|||
| تاريخ= نوفمبر 2011 |
|||
| مسار أرشيف = https://web.archive.org/web/20200502202126/https://tools.ietf.org/html/rfc6437 |
|||
| مسار= https://tools.ietf.org/html/rfc6437 |
|||
| عنوان= RFC 6437, IPv6 Flow Label Specification |
|||
| لغة= en |
|||
| doi = 10.17487/RFC6437 |
|||
|تاريخ أرشيف=2020-05-02}} |
|||
* {{استشهاد ويب |
|||
| الأخير= Deering |
|||
| الأول= S. |
|||
| الأخير2= Hinden |
|||
| الأول2= R. |
|||
| تاريخ= يوليو 2017 |
|||
| مسار أرشيف = https://web.archive.org/web/20191211094548/https://tools.ietf.org/html/rfc8200 |
|||
| مسار= https://tools.ietf.org/html/rfc8200 |
|||
| عنوان= RFC 8200, Internet Protocol, Version 6 (IPv6) Specification |
|||
| موقع= The Internet Society |
|||
| لغة= en |
|||
| doi = 10.17487/RFC8200 |
|||
| تاريخ الوصول= 30 مايو 2019 |
|||
| تاريخ أرشيف=2019-12-11}} |
|||
</div> |
|||
== وصلات خارجية == |
== وصلات خارجية == |
||
سطر 1٬814: | سطر 866: | ||
{{شريط سفلي الإصدار السادس من بروتوكول الإنترنت}} |
{{شريط سفلي الإصدار السادس من بروتوكول الإنترنت}} |
||
{{ضبط استنادي}} |
{{ضبط استنادي}} |
||
{{شريط بوابات|اتصال عن بعد| |
{{شريط بوابات|إنترنت|اتصال عن بعد|تقانة المعلومات|علم الحاسوب}} |
||
{{شريط محتوى متميز|1=مختارة|التاريخ=12 مايو 2021|النسخة=|تاريخ مراجعة الزملاء=2 مارس |
{{شريط محتوى متميز|1=مختارة|التاريخ=12 مايو 2021|النسخة=53803577|تاريخ مراجعة الزملاء=2 مارس 2021}} |
||
[[تصنيف: |
[[تصنيف:استحداثات متعلقة بالحواسيب في 1995]] |
||
[[تصنيف: |
[[تصنيف:استحداثات متعلقة بالحواسيب في 1996]] |
||
[[تصنيف:الإصدار السادس من بروتوكول الإنترنت]] |
[[تصنيف:الإصدار السادس من بروتوكول الإنترنت]] |
||
[[تصنيف:بروتوكولات تشبيك]] |
[[تصنيف:بروتوكولات تشبيك]] |
النسخة الحالية 06:09، 31 يوليو 2024
الإصدار السادس من بروتوكول الإنترنت | |
---|---|
ترويسة الإصدار السادس من بروتوكول الإنترنت
| |
اختصار | IPv6 |
الوظيفة | بروتوكول تشبيك |
المُطوِّر | مجموعة مهندسي الإنترنت |
تاريخ التطوير | ديسمبر 1995م |
حل محل | الإصدار الرابع من بروتوكول الإنترنت |
تأثَّر بـ | الإصدار الرابع من بروتوكول الإنترنت |
طبقة نموذج OSI | طبقة الشبكة |
تعديل مصدري - تعديل ![]() |
الإصدار السادس من بروتوكول الإنترنت (بالإنجليزية: Internet Protocol Version 6 اختصارًا IPv6) هو بروتوكول تشبيك يعمل في طبقة الشبكة حسبَ نموذج الربط البيني للأنظمة المفتوحة، يُستعمل هذا البروتوكول في شبكات البيانات ويقدم خدمات العنونة والتقطيع وإدارة حركة البيانات.[ar 1] طوِّر الإصدار السادس في عام 1995م على يد مجموعة مهندسي الإنترنت بصفته حلًّا نهائيًّا لمشكلة استنفاد فضاء عناوين الإصدار الرابع من بروتوكول الإنترنت.[1]
يُعرِّف البروتوكول ترويسة ثابتة الطول: 40 بايتًا، تضاف إلى جميع رزم البيانات التي يُنشئها، وتوجد أيضًا مجموعة من ترويسات التوسعة التي يمكن استخدامها بشكل اختياري حسب الحاجة عند أداء وظائف معينة مثل التقطيع والتوجيه. يمكن أن تحتوي رزمة بيانات الإصدار السادس على أكثر من ترويسة توسعة تلي ترويسة البروتوكول.[2]
يُعرِّف البروتوكول فضاءً من العناوين يضم قرابة 3.4x1038 عنوانًا طول كل منها 128 بتًّا.[3] يُقسَّم الفضاء رياضيًّا إلى فضاء البث فريد الوجهة وإلى فضاء البث المجموعاتي، وتدير هيئة العناوين المُخصصة كلا الفضاءَين. يدعم البروتوكول ثلاثة أنماط من العنونة هي العنونة فريدة الوجهة وعنونة البث نحو الأقرب وعنونة البث المجموعاتي، ولا يدعم البث العام.[4]
تصف مُحددات البروتوكول آليةً لتقطيع رزم البيانات في مصادرها فقط، وذلك لأن البروتوكول يدعم أيضًا آليةً لاكتشاف حجم وحدة النقل العظمى لمسار رزمة بيانات ما قبل إرسالها، فيختار طول رزمة متوافقًا معه، ولا حاجة لإجراء التقطيع في عقد الشبكة الموجودة على المسار كما هو الحال في الإصدار الرابع من البروتوكول. في الوجهة النهائية، تحصل عملية إعادة التجميع، وفيها يعاد تشكيل الرزمة الأصلية انطلاقًا من القطع المُستقبلة.[5]
يدعم الإصدار السادس أيضًا آليتين لإدارة حركة البيانات في الشبكة. الآلية الأولى هي تعريف تدفقات لرزم البيانات، وهي طريقة لتحديد مجموعة من الرزم المرسلة من مصدر محدد إلى وجهة محددة، ويُستعمل لأجل ذلك حقل مخصص في ترويسة البروتوكول.[6] أما الآلية الثانية فهي دعم مستويات متعددة لجودة الخدمة في الشبكة، ثم تحديد المستوى المطلوب لكل رزمة باستعمال حقل مُخصص لذلك في ترويسة البروتوكول. في كلتا الآليتين، لا يحدد البروتوكول كيفية معالجة الرزم بشكل تفضيلي، ولكنه يشرح كيفية تمييزها في المرحلة التي تسبق معالجتها.[7]
ينشأ عن استعمال الإصدار السادس من بروتوكول الإنترنت مجموعة من الثغرات الأمنية التي قد تكون منطلقًا لمجموعة من الهجمات، بعضها مرتبط بالتقطيع مثل هجوم القطعة الصغيرة أو هجوم القطع المتراكبة،[ar 2] وبعضها مرتبط بإدارة حركة رزم البيانات مثل هجوم سرقة الخدمة.[8]
نبذة تاريخية
[عدل]![](http://upload.wikimedia.org/wikipedia/commons/thumb/e/e9/IPv4_classes-ar.svg/300px-IPv4_classes-ar.svg.png)
![](http://upload.wikimedia.org/wikipedia/commons/thumb/d/da/TCP_and_IP_protocols_development_timeline-ar.svg/300px-TCP_and_IP_protocols_development_timeline-ar.svg.png)
![](http://upload.wikimedia.org/wikipedia/commons/thumb/a/af/IPv6_timeline-ar.svg/300px-IPv6_timeline-ar.svg.png)
بدءًا من سبعينيات القرن العشرين، ابتدأ نمو وانتشار شبكة بيانات حول العالم، كانت نقطة الانطلاق من المراكز البحثية والجامعات في الولايات المتحدة الأمريكية، وسُميت هذه الشبكة بالأربانت في بداياتها. اعتمدت هذه الشبكة على مجموعة من البروتوكولات التي طورتها وكالة مشاريع البحوث المتطورة الدفاعية، ومنها الإصدار الرابع من بروتوكول الإنترنت الذي استخدم لعنونة التجهيزات المُتصلة مع الشبكة بصورة فريدة عالميًّا.[9] في مطلع التسعينيات، بدأ استخدام الإنترنت تجاريًّا، وأصبح من الشائع تقديم الخدمات أو بيع المُنتجات عبر الإنترنت، وسبب هذا نموًا سريعًا للشبكة خاصة في الولايات المُتحدة الأمريكية.[10]
اعتمد الإصدار الرابع من بروتوكول الإنترنت على نظام عنونة مبني على فضاء يبلغ طول العنوان فيه 32 بتًّا، وُقسِّم هذا الفضاء إلى أصناف، خُصصت ثلاثٌ منها لعنونة البث فريد الوجهة، وهي الصنف A وعدد أفضيته 128 صنفًا، وهو أكبر الأصناف حجمًا (224 عنوانًا في كل صنف)، والصنف B وضمَّ الفضاء 214 صنفًا في كل منها 216 عنوانًا، والصنف C وهو أكثر الأصناف عددًا بواقع 221 صنفًا، ولكنها أصغرها حجمًا، حيث يضمّ كل صنف 28 عنوانًا.[11][12] وخُصص فضاء رابع للبث المجموعاتي، وسمي الصنف D.[13]
شكَّلت مجموعة مهندسي الإنترنت، وهي الهيئة الناظمة لتطوير معايير الإنترنت، في شهر نوفمبر من العام 1991م، مجموعة عمل التوجيه والعنونة والمعروفة اختصارًا باسم رُوْد (بالإنجليزية: Routing and Addressing اختصاراً ROAD) بهدف معالجة هذه المشكلة، وعرَّفت هذه المجموعة ثلاثَ مُشكلات رئيسيَّة تعيق نمو الإنترنت:[14]
- استنفاد فضاء عناوين الصنف B، وهذه هي نتيجة لغياب فضاء عناوين يناسب منظمة متوسطة الحجم، ففضاء الصنف C صغير الحجم، وهو ما يدفع هذه المنظمات لاستعمال فضاء من الصنف B، على الرغم من أن حجم الفضاء يزيد بكثير عن حاجة المنظمة.
- نمو جداول التوجيه في موجهات الإنترنت لتصبح بحاجة إلى قدرات معالجة غير متوافرة بالبرمجيات أو المعدات المتوافرة.
- الاستنفاد النهائي لفضاء عناوين الإصدار الرابع.
لقد كانت المشكلتان الأولى والثانية وشيكتا الحصول، وكان يتوقع حصول أيٍّ منهما بدءًا من العام 1993م.[15] نتيجة لذلك، طوِّرت الحلول ضمن إستراتيجيتين، تشمل الأولى حلولًا سريعة التطبيق قصيرة الأمد، وهي تستهدف المشكلتان الأولى والثانية، أمَّا الثانية، فتُعنى بحلٍ نهائيٍّ دائمٍ طويل الأمد.[16] طوِّر التوجيه غير الصنفي بين النطاقات في العام 1992م في إطار الإستراتيجية الأولى،[14] وتلاه تقنية ترجمة عنوان الشبكة في العام 1994م.[17] نجحت حلول الإستراتيجية قصيرة الأمد في إطالة عمر الإصدار الرابع من بروتوكول الإنترنت من خلال إبطاء استنفاد الفضاء.[18] ولكن وعلى أي حال، فبعد أكثر من عقد من الزمن، وتحديدًا في شهر يناير من العام 2011م، استُنفد فضاء عناوين الإصدار الرابع من بروتوكول الإنترنت على المستوى العالمي تمامًًا.[Web 1]
في ما يخص الإستراتيجية طويلة الأمد، فقد بدأت مجموعة مهندسي الإنترنت في العمل منذ مطلع التسعينيات على تطوير إصدار جديد من بروتوكول الإنترنت. في العام 1993م، كان التوجه العام هو طرح نظام عنونة جديد موسع في إصدار جديد من بروتوكول الإنترنت، ولذلك طلبت المجموعة اقتراحات في هذا الشأن مع نهاية تلك السنة.[19] في نهاية العام 1993م أيضًا، شكّلت المجموعة نطاق عمل جديد سمته الجيل التالي من بروتوكول الإنترنت (بالإنجليزية: IP Next Generation اختصاراً IPng)،[20] وعمل 15 مهندسًا من اختصاصات متنوعة على مراجعة ودراسة الاقتراحات لصياغة حل شامل.[21]
في شهر ديسمبر من العام 1995، صدر المعيار الأول للإصدار السادس من بروتوكول الإنترنت تحت الاسم الرمزي RFC 1883.[1] وصدر معه أيضًا المعياران الأولان لمُحددات بنية العناوين في الإصدار السادس ولبروتوكول رسائل التحكم للإصدار السادس، وحملت وثائق طلب التعليقات الخاصة بهما الاسمين الرمزيين RFC 1884 وRFC 1885 على الترتيب.[22][23] صدر المعياران الأولان لبروتوكول اكتشاف الجيران ولآلية التهيئة الذاتية الآلية لاحقًا في شهر أغسطس من العام التالي، وحملا الاسمين الرمزيين على RFC 1970 وRFC 1971 على الترتيب.[24][25]
صدرت مجموعة تحديثات جديدة تضمنت أربعة وثائق طلب تعليقات تمتد أسماؤها الرمزية من RFC 2460 حتى RFC 2463 في ديسمبر من العام 1998م، وشملت معاييرَ جديدةً للإصدار السادس، ولبروتوكول رسائل التحكم الخاص به ولبروتوكول اكتشاف الجيران ولآلية التهيئة الذاتية الآلية.[26][27] واستمرت التحديثات بالصدور منفصلة أو بشكل مجموعات، فصدرت ثلاث معايير متتابعة لبنية عناوين الإصدار السادس، آخرها في فبراير من العام 2006م، وحمل الاسم الرمزي RFC 4291،[28] وصدر معيارٌ ثالث لبروتوكول رسائل التحكم للإصدار السادس في مارس من العام 2006م أيضًا، وحمل الاسم الرمزي RFC 4443،[29] وصدر ثالثًا زوجان من المعايير أحدهما لبروتوكول اكتشاف الجيران والآخر لآلية التهيئة الذاتية الآلية في فبراير 2007م وحملا الاسمين الرمزيين على RFC 4861 وRFC 4862 على الترتيب.[30][31] وأخيرًا صدر المعيار الحالي للإصدار السادس من بروتوكول الإنترنت في يونيو من العام 2017م وحمل الاسم الرمزي RFC 8200.[32]
مبدأ العمل
[عدل]جزء من سلسلة مقالات حول |
بروتوكول الإنترنت |
---|
![]() |
الإصدار السادس من بروتوكول الإنترنت هو بروتوكول تشبيك يعمل في طبقة الشبكة في نموذج الربط البيني للأنظمة المفتوحة، ويُشرف على مهام العنونة وتقطيع رزم البيانات ويساهم في إدارة حركة البيانات في الإنترنت.[33] صُمم الإصدار السادس من بروتوكول الإنترنت ليحل محل الإصدار الرابع، وليعالج المشكلات الناجمة عن استعماله والتي تتلخص بفضاء عناوين محدود الحجم وبنية ترويسة معقدة ودعم محدود لإمكانية إضافة توسيعات جديدة للأصل. بالإضافة لمعالجة هذه المشكلات، فقد امتلك الإصدار السادس إمكانيات جديدة مثل إنشاء تدفقات من رزم البيانات وتمييزها بلافتات خاصة تتيح إمكانية لتقديم مستويات مختلفة من جودة الخدمة، ومثل دعم توسيعات جديدة اختيارية للمسائل الأمنية تشمل دعم المصادقة وخصوصية البيانات.[34]
بشكل مشابه للإصدار الرابع، يقدم الإصدار السادس خدمتي العنونة والتقطيع.[35] في ما يخص العنونة فإن الإصدار السادس من بروتوكول الإنترنت يُعرِّف فضاء عناوين يضم 2128 عنوانًا، ويدعم ثلاثة أنماط من العنونة: هي عنونة البث فريد الوجهة، وعنونة البث المجموعاتي وعنونة البث نحو الأقرب، أما البث العام فهو غير مدعوم في هذا البروتوكول.[4] في ما يخص التقطيع، يمكن للبروتوكول أن يقطع رزم بيانات الإصدار السادس في مصدرها فقط، وأن يعيد تجميع القطع في وجهتها النهائية فقط، ولا حاجة لتقطيع الرزم على طول المسار، وذلك لامتلاك مصدر رزم البيانات آليةً للتعرف على حجم وحدة النقل العظمى للمسار قبل البدء بالإرسال، ما يسمح له باختيار الحجم المناسب وتقطيع رزمة البيانات على أساسه.[36]
أما في ما يخص إدارة حركة البيانات، يدعم البروتوكول آليتين منفصلتين هما الإدارة باستعمال تدفق البيانات والإدارة باستعمال صنف الخدمة. في ما يخص إنشاء تدفقات رزم البيانات، فهي آلية يدعمها للبروتوكول تسمح بتعريف مجموعة محددة رزم البيانات التي تُنقل بين مصدر لرزم البيانات ووجهة واحدة لها على الأقل. وتُعرِّف هذه الآلية التدفق بأنّه مجموعة من كلُ رزم البيانات التي تنتقل في اتجاه واحد عبر قناة اتصال مُحددة. ولا يلزم أن يكون المضيف الوجهة فريدًا فيمكن لهذه الآلية أن تدعم بالإضافة لرزم البث فريد الوجهة رزمَ البث المجموعاتي ورزمَ البث نحو الأقرب.[37] تساعد عملية إنشاء تدفقات الرزم على تصنيف حركة البيانات وتقديم الخدمة المناسبة لها اعتمادًا على ترويسة بروتوكول الإصدار السادس فقط من غير الحاجة لترويسات الطبقات العليا.[6] أما في ما يخص استعمال صنف الخدمة، فهي آلية مشابهة لما طُبِّق في الإصدار الرابع من البروتوكول، وفيها يُستعمل حقل صنف الخدمة لتعريف أصناف مختلفة من الخدمات المطلوبة، ويُصار بعدها إلى معالجة كل رزمة وتقديم الخدمات إليها وفقًا لقيمة هذا الحقل فيها.[7]
بالإضافة لذلك، تُعرِّف مُحددات البروتوكول المُصطلحات التالية وتستخدمها وثائق طلب التعليقات ذات الصلة:[38]
- عنوان البروتوكول: وهو مُعرِّف رقمي يخص طبقة الشبكة يُمكن أن يمُنح لمنفذ واحد أو لعدة منافذ معًا.
- العقدة: هي أي جهاز في الشبكة يُطبِّق البروتوكول.
- الموجه: هو عقدة تنجز عملية التوجيه لرزم بيانات لم تولدها للإصدار السادس من بروتوكول الإنترنت.
- المُضيف: هو أي عقدة ما خلا الموجهات.
- الوصلة: هي وسط اتصال على مستوى طبقة الوصلة، يمكن للعقد أن تتواصل بعضها مع بعض عبرها.
- الجيران: بالنسبة لعقدة ما متصلة مع وصلة واحدة أو أكثر، فإنَّ الجيران هم جميع العقد التي تتصل مع تلك الوصلة أو الوصلات.
الترويسات
[عدل]![](http://upload.wikimedia.org/wikipedia/commons/thumb/a/a9/IPv6_headers_sequence-ar.svg/300px-IPv6_headers_sequence-ar.svg.png)
تتابع الترويسات
[عدل]يُضيف الإصدار السادس من بروتوكول الإنترنت ترويسة خاصة به في عملية التغليف عند إنشاء رزمة البيانات، وطول هذه الترويسة ثابت وهو 40 بايت دائمًا.[39] يمكن أيضًا أن تضاف معلومات أخرى تخصّ طبقة الشبكة في ترويسات خاصة تُسمَّى ترويسات التوسعة، تضاف بشكل اختياري بعد ترويسة بروتوكول الإصدار السادس، وقبل ترويسة بروتوكول الطبقة العليا. ولترويسات التوسعة أنواع هي: ترويسة خيارات المسار وترويسة القطعة وترويسة خيارات الوجهة وترويسة التوجيه وترويسة التحقق من الهوية وترويسة تأمين الحمولة بالتغليف.[40]
لكل نوع ترويسة مُعرِّف مُحدد، وتحتوي الترويسات جميعها، بما في ذلك ترويسة الإصدار السادس، على حقل مُخصص ليضم قيمة مُعرِّف نوع الترويسة التالية، ويسمح ذلك بإمكانية إنشاء تتابع من الترويسات، حيث تشير قيمة حقل المُعرِّف في كل ترويسة إلى نوع الترويسة التالية،[39] في حين تُخصص القيمة 59 للإشارة إلى عدم وجود ترويسة تالية وتستعمل في الترويسة الموجودة في نهاية التتابع.[41][42] تدير هيئة أرقام الإنترنت المُخصصة ضبط القيم المعيارية لمُعرفات أنواع الترويسة.[Web 2] وإذا وردت عدة ترويسات، فتكون بالترتيب التالي:[43](1)
- ترويسة بروتوكول الإنترنت
- ترويسة خيارات المسار
- ترويسة خيارات الوجهة (للخيارات التي ستعالج في الوجهة الأولى على المسار أو أي وجهة بينية أخرى مُحددة بترويسة التوجيه ما خلا الوجهة النهائية)
- ترويسة التوجيه
- ترويسة القطعة
- ترويسة تأمين الحمولة بالتغليف
- ترويسة خيارات الوجهة (للخيارات التي ستُعالج في الوجهة النهائية فقط)
- ترويسة بروتوكول الطبقة العليا
يجب أن يكون طول ترويسة التوسعة عددًا صحيحًا من مضاعفات 8 بايت، أي 16 و24 و32 إلخ ... وذلك ضروريٌ لمحاذاة الترويسات المتتابعة، وتضم بعض الترويسات عددًا من الخيارات التي يكون لها بنية محددة أيضًا بحيث تصطف وتُحاذَى تلقائيًَّا داخل الترويسة.[40]
فيما خلا ترويسة خيارات المسار، لا تُعالَج أي ترويسة على طول مسار رزمة، ولا تضاف أي ترويسة لرزمة البيانات أو تحذف منها حتى تبلغ الرزمة العنوان المحدد بعنوان الوجهة في ترويسة البروتوكول.[44](2) إنَّ وجود ترويسات التوسعة في رزمة بيانات ما هو مسألة اختيارية، أما دعمها فهو إلزامي في أي تنفيذ للإصدار السادس من البروتوكول،[40] ولكن توجد ترويسات أخرى مُعرَّفة لأغراض خاصة، لا يلزم أن تكون مدعومة في كل تنفيذ، منها على سبيل المثال ترويسة خيارات الحركة [45] ترويسة بروتوكول هوية المضيف [الإنجليزية].[46]
بنى الترويسات
[عدل]ترويسة البروتوكول
[عدل]![](http://upload.wikimedia.org/wikipedia/commons/thumb/5/5c/IPv6_header-ar.svg/300px-IPv6_header-ar.svg.png)
يبلغ طول ترويسة الإصدار السادس 40 بايت، وتتكون من ثمانية حقول هي وفقًا لترتيب وردوها:[47]
- حقل رقم الإصدار: وطوله 4 بت، ويمثل رقم الإصدار، وقيمته هي 6 دائمًا في ترويسة الإصدار السادس من بروتوكول الإنترنت.
- حقل صنف حركة البيانات: وطوله 8 بت، ويحتوي مُعرِّف رقمي يمكن ضبطه لتحديد جودة الخدمة التي ستحصل عليها رزمة البيانات.
- حقل لافتة التدفق: وطوله 20 بت، ويحتوي مُعرِّف رقمي يُحدد التدفق الذي تنتمي إليه رزمة البيانات، ويمكن أن تستعمل هذه القيمة في تحديد كيفية معالجة الرزمة في الموجهات التي تعالج الرزمة على طول المسار نحو وجهتها.
- حقل طول الحمولة: وطوله 16 بت، ويحتوي عدد صحيح موجب يمثل طول حمولة الرزمة التي توجد فيها الترويسة مُقدرًا بالبايت، يشمل ذلك ترويسات التوسعة جميعها والتي تلي ترويسة الإصدار السادس.
- حقل الترويسة التالية: وطوله 8 بت، ويحدد نوع الترويسة التالية، التي تلي هذه الترويسة، إذا كانت الترويسة مغايرة لترويسات التوسعات، فإن قيم هذه الحقل مُطابقة للقيم المُستعملة في الإصدار الرابع من البروتوكول.[Web 3]
- حقل عدد القفزات: وطوله 8 بت، ويحتوي عددًا صحيحًا موجبًا. ينقص كل موجه يُعالج رزمة البيانات ويُوجِّههها واحدًا من هذه القيمة. يفحص كل موجه يستقبل رزمة البيانات قيمة هذا الحقل أولًا، إذا كانت مساوية للصفر، فإنه يتخلص منها. إذا استقبلت الوجهة النهائية الرزمة بقيمة صفرية لهذا الحقل، لا تتخلص منها بل تعالجها.
- حقل عنوان المصدر: وطوله 128 بت، عنوان العقدة المصدر التي ولدت رزمة البيانات.
- حقل عنوان الوجهة: وطوله 128 بت، عنوان وجهة الرزمة. قد يحتوي عنوان الوجهة الأخيرة، أو عنوان المُستقبل التالي للرزمة إذا كانت ترويسة التوجيه موجودة بعد ترويسة البروتوكول.
ترويسة خيارات المسار
[عدل]![](http://upload.wikimedia.org/wikipedia/commons/thumb/9/9f/Hop-by-Hop_and_Destination_option_headers_structure-ar.svg/300px-Hop-by-Hop_and_Destination_option_headers_structure-ar.svg.png)
تستعمل ترويسة خيارات المسار (بالإنجليزية: Hop-by-hop options header) لحمل معلومات لخيارات يُمكن فحصها أو معالجة محتواها في كل مُوجِّه تمر به الرزمة عبر مسارها إلى وجهتها النهائية. إن قيمة النوع الخاصة بهذه الترويسة هي 0، وإذا وردت هذه الترويسة في رزمة بيانات، فيجب أن تُوضع هذه القيمة في حقل الترويسة التالية الموجود داخل الترويسة السابقة.[48]
طول ترويسة خيارات المسار مُتغيِّرٌ، وهي تتكون من حقلين ثابتي الطول يليهما حقل واحد مُتغيِّر الطول، وهذه الحقول هي وفقًا لترتيب ورودها:[48]
- حقل الترويسة التالية: طوله 8 بت، ويحتوي قيمة تُعرِّف نوع الترويسة الموجودة مباشرةً بعد هذه الترويسة.
- حقل طول ترويسة التوسعة: وطوله 8 بت، ويحتوي عدد صحيح موجب يمثل طول ترويسة خيارات المسار بواحدة 8 بايت، دونَ احتساب البايتات الثمانية الأولى. مثلًا إذا كان طول الترويسة هو 16 بايت، فإن قيمة هذا الحقل هي 1، وإذا كان طول الترويسة هو 32 بايت فإن قيمة هذا الحقل هي 3.
- حقل الخيارات: مُتغيِّر الطول، يضم خيارًا واحدًا أو أكثر من خيارات المسار، ويلزم يكون طول هذا القسم متوافقًا مع واحدة 8 بايت، أي من المقبول أن يكون الطول: 8 أو 16 أو 24 بايت ... إلخ.
ترويسة التوجيه
[عدل]![](http://upload.wikimedia.org/wikipedia/commons/thumb/e/ef/Routing_header_structure-ar.svg/300px-Routing_header_structure-ar.svg.png)
يستعمل مصدر رزمة بيانات للإصدار السادس من بروتوكول الإنترنت ترويسة التوجيه (بالإنجليزية: Routing header) لتحديد مسارها أو جزءًا منه من خلال إضافة قائمة تضم عناوين العقد الوسيطية التي يلزم أن تزورها الرزمة عبر مسارها وصولًا إلى وجهتها.[49] تتشابه وظيفة هذه الترويسة مع وظيفة خيار المسار الحرّ من المصدر في الإصدار الرابع من بروتوكول الإنترنت.[50] إن قيمة النوع الخاصّ بترويسة التوجيه هي 43، وإذا وردت هذه الترويسة في رزمة بيانات، فيجب أن تُوضع هذه القيمة في حقل الترويسة التالية الموجود داخل الترويسة السابقة.[51]
ترويسة التوجيه متغيرة الطول، وهي تتكون من أربعة حقول ثابتة الطول يليها حقل وحيد متغير الطول، وهذه الحقول هي وفقًا لترتيب ورودها:[51]
- حقل الترويسة التالية: طوله 8 بت، ويحتوي قيمة تُعرِّف نوع الترويسة الموجودة مباشرةً بعد هذه الترويسة.
- حقل طول ترويسة التوسعة: طوله 8 بت، ويحتوي عدد صحيح موجب يمثل طول ترويسة خيارات المسار بواحدة 8 بايت، دونَ احتساب البايتات الثمانية الأولى.
- حقل نوع التوجيه: طوله 8 بت، ويضمّ مُعرفًا يُحدد نوع التوجيه، وتحدد هيئة أرقام الإنترنت المُخصصة قائمة المُعرفات المدعومة من قبل البروتوكول ومعاني كلٍّ منها.[Web 4] اعتمد النوع ذو القيمة 0 في المعيار الأصلي، لكنه أُبطل لأسباب أمنية.(3)[52]
- حقل القطاعات المتبقية: طوله 8 بت، ويضمّ معرِّفًا رقميًّا لعدد قطاعات الشبكة الوسيطية(4) التي يلزم زيارتها قبل الوصول إلى الوجهة النهائية، ولكنَّها لما تُزر بعدُ.
- حقل بيانات مُرتبطة بالنوع: مُتغيِّر الطول، ويحتوي مجموعة واحدة أو أكثر من هياكل البيانات التي يكون طولها متوافقًا مع واحدة 8 بايت، لتكون نهايتها عند نهاية الترويسة دائمًا، أما بنية الهياكل، فهي تتحدد بنوع التوجيه.
توجد حالتان مرتبطتان بترويسة التوجيه تستوجبان إرسال رسائل أخطاء خاصَّة ببروتوكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت، وهما:[53]
- إذا استقبلت عقدة ما، مغايرة للوجهة النهائية، رزمة بيانات تحتوي ترويسة التوجيه، وكان نوع التوجيه غيرَ معروف، ويجب عندها التخلص من الرزمة أيضًا قبل إرسال رسالة الخطأ. أما إذا كانت العقدة هي الوجهة النهائية، فتُهمل الترويسة وتعالج الرزمة.
- إذا كان توجيه الرزمة لازمًا عبر شبكة ما، ولكن حجمها أكبر من حجم وحدة النقل العظمى للشبكة، وعندها يجب على العقدة التي تُوجِّه الرزمة أن تتخلص منها قبل أن ترسل رسالة الخطأ المناسبة إلى مصدر البروتوكول.
ترويسة القطعة
[عدل]![](http://upload.wikimedia.org/wikipedia/commons/thumb/7/7c/Fragment_header_structure-ar.svg/300px-Fragment_header_structure-ar.svg.png)
تضاف ترويسة القطعة (بالإنجليزية: Fragment header) إلى جميع القطع الناتجة عن عملية تقطيع رزمة بيانات.[54] إنَّ قيمة النوع الخاصة بهذه الترويسة هي 44، وإذا وردت هذه الترويسة في رزمة بيانات، فيجب أن تُوضع هذه القيمة في حقل الترويسة التالية الموجود داخل الترويسة السابقة.[Web 5]
يبلغ طول ترويسة القطعة 8 بايت، وتتألف من 6 حقول دائمة، هي وفقًا لترتيب وردوها:[55]
- حقل الترويسة التالية: طوله 8 بت، ويضبط بشكل مشابه لحقل الترويسة التالية في ترويسة البروتوكول الأصلية.
- حقل محجوز طوله 8 بت، يُضبط إلى قيمة صفرية في مصدر الرزمة عند الإرسال.
- حقل إزاحة القطعة: طوله 13 بت، يحتوي موقع حمولة القطعة النسبي ضمن حمولة الرزمة الأصلية، وتعبر قيمة الرقم الموجود عن الإزاحة بواحدة هي 8 بايت، فإذا كانت قيمة هذا الحقل مثلًا هي 2، فإن إزاحة القطعة الحقيقية هي 16 بايت.
- حقل محجوز طوله 2 بت، يُضبط إلى قيمة صفرية في مصدر الرزمة عند الإرسال.
- علم المزيد من القطع: طوله 1 بت، ويستخدم للإشارة إلى القطعة الأخيرة، إذا كانت قيمته 1، فهذا يعني وجود قطع لاحقة نتجت عن عملية التقطيع، أما إذا كانت قيمته 0 فذلك يعني بأنَّ هذه القطعة هي القطعة الأخيرة.
- حقل مُعرّف القطعة طوله 32 بت، وهي يحتوي قيمة فريدة تُميّز الرزمة الأصلية وجميع القطع التي نتجت عن تقطيعها. توجد خوارزميات عديدة لاختيار قيمة المعرّف بحيث يكون فريدًا وآمنًا، وهي موصوفة في وثيقة طلب التعليقات RFC 7739.[56]
ترويسة خيارات الوجهة
[عدل]![](http://upload.wikimedia.org/wikipedia/commons/thumb/9/9f/Hop-by-Hop_and_Destination_option_headers_structure-ar.svg/300px-Hop-by-Hop_and_Destination_option_headers_structure-ar.svg.png)
تُستخدم ترويسة خيارات الوجهة (بالإنجليزية: Destination Options Header) لحمل الخيارات التي تُعالجها الوجهة النهائية للرزمة فقط. إنَّ قيمة النوع الخاصّ بترويسة التوجيه هي 60، وإذا وردت هذه الترويسة في رزمة بيانات، فيجب أن تُوضع هذه القيمة في حقل الترويسة التالية الموجود داخل الترويسة السابقة.[57]
ترويسة خيارات الوجهة مُتغيَّرة الطول، وهي تتكون من حقلين ثابتي الطول يليهما حقل وحيد متغير الطول، وهذه الحقول هي وفقًا لترتيب ورودها:.[57]
- حقل الترويسة التالية: طوله 8 بت، ويحتوي قيمة تُعرِّف نوع الترويسة الموجودة مباشرةً بعد هذه الترويسة.
- حقل طول ترويسة التوسعة: وطوله 8 بت، ويحتوي عدد صحيح موجب يمثل طول ترويسة خيارات المسار بواحدة 8 بايت، دونَ احتساب البايتات الثمانية الأولى.
- حقل الخيارات: متغيِّر الطول، يضم خيارًا واحدًا أو أكثر من خيارات الوجهة، ويلزم أن يكون طول هذا القسم متوافقًا مع واحدة 8 بايت، أي من المقبول أن يكون الطول: 8 أو 16 أو 24 بايت ... إلخ.
ترويسة المصادقة
[عدل]![](http://upload.wikimedia.org/wikipedia/commons/thumb/a/a4/Authentcation_header_structure-ar.svg/300px-Authentcation_header_structure-ar.svg.png)
تُؤَمِّن ترويسة المصادقة (بالإنجليزية: Authentication Header) آليةً للتحقق من سلامة رزم البيانات المنقولة عبر اتصال يجري عبر قناة غير مُهيَّأة وتحققًا من هوية مصدر هذه الرزمة. تسمح آلية التحقق من السلامة بمنع تلاعب وسيط ما برزم البيانات عند حركتها بين مصدرها ووجهتها، وتستخدم في التصدي لهجمات الوسيط.[58] إنَّ قيمة النوع الخاصّ بترويسة المصادقة هي 51، وإذا وردت هذه الترويسة في رزمة بيانات، فيجب أن تُوضع هذه القيمة في حقل الترويسة التالية الموجود داخل الترويسة السابقة.[59]
ترويسة خيارات الوجهة مُتغيَّرة الطول، وهي تتكون من ستة حقول، خمسةٌ منها ثابتة الطول يليها حقل وحيد متغير الطول، وهذه الحقول هي وفقًا لترتيب ورودها:[60]
- حقل الترويسة التالية: طوله 8 بت، ويحتوي قيمة تُعرِّف نوع الترويسة الموجودة مباشرةً بعد هذه الترويسة.
- حقل طول الحمولة: طوله 8 بت، ويحتوي طول ترويسة التوسعة بواحدة 32 بت، أو 4 بايت، منقوصًا منها بايتان. أي إذا كان طول الترويسة هو 100 بايت، فإن قيمة هذا الحقل هي 2-(100/4)= 2-25 = 23.
- حقل محجوز: بطول 16 بت.
- حقل فهرس وسائط الأمن: بطول 32 بت، ويحتوي مُعرِّف الجلسة الآمنة، وهي قيمة عشوائية يضيفها المصدر إلى الترويسة وتُستخدم من قبل الوجهة لتمييز الجلسة الآمنة التي أرسلت الرزمة عبرها.
- حقل رقم التتابع: بطول 32 بت، يحتوي عداد تضبط قيمته في المصدر إلى قيمة محددة مع بدء الجلسة الآمنة، ثم قيمة التتابع بمقدار واحد مع كل رزمة بيانات تُرسل في الجلسة.
- حقل قيمة التحقق من السلامة: متغيِّر الطول، ويلزم أن يكون طوله من مضاعفات 32 بت، ويُضمُّ قيمة رياضية تُحسب في العقدة المصدر من أجل محتويات رزمة البيانات التي لا تتغير خلال عبورها الشبكة. في العقدة الوجهة، لا يمكن الحصول على قيمة حقل التحقق من السلامة نفسِها إلا إذا كانت محتويات الرزمة هي نفسُها، أي أنها وصلت من المصدر إلى الوجهة دونَ تلاعب فيها.
ترويسة تأمين الحمولة بالتغليف
[عدل]![](http://upload.wikimedia.org/wikipedia/commons/thumb/5/52/Encapsulating_Security_Payload-ar.svg/300px-Encapsulating_Security_Payload-ar.svg.png)
تُستعمل ترويسة تأمين الحمولة بالتغليف (بالإنجليزية: Encapsulating Security Payload header) لتأمين مجموعة من خدمات الأمن التي تشمل: سرية البيانات وللتحقق من هوية مصدرها ولسلامة الاتصال عبر القنوات غير المُهيَّأة وللحماية من الهجمات المضادة لإعادة الإرسال (بالإنجليزية: Anti-replay attacks).[61] إنَّ قيمة النوع الخاصّ بترويسة التوجيه هي 50، وإذا وردت هذه الترويسة في رزمة بيانات، فيجب أن تُوضع هذه القيمة في حقل الترويسة التالية الموجود داخل الترويسة السابقة.[62]
ترويسة تأمين الحمولة بالتغليف مُتغيَّرة الطول، وهي تتكون من سبعة حقول، أربعة منها ثابتة الطول. وحقول هذه الترويسة هي وفقًا لترتيب ورودها:[63]
- حقل فهرس وسائط الأمن: بطول 32 بت. ويحتوي مُعرِّف الجلسة الآمنة، وهي قيمة عشوائية يضيفها المصدر إلى الترويسة وتُستخدم من قبل الوجهة لتمييز الجلسة الآمنة التي أرسلت الرزمة عبرها.
- حقل رقم التتابع: بطول 32 بت. يحتوي عداد تضبط قيمته الابتدائية في المصدر إلى قيمة محددة عند بدأ الجلسة الآمنة، ثم تُزاد قيمة التتابع بمقدار واحد مع كل رزمة بيانات يُرسلها مصدر الرزم في تلك الجلسة.
- حقل بيانات الحمولة: مُتغير الطول، يحتوي المعلومات التي تُعمَّى من أجل حمايتها.
- حقل الحشو: متغير الطول يتراوح طوله بين 0 و 255 بايت، يحتوي بايتات إضافية مُلحقة بالحمولة. يُضاف حقل الحشو لسببين:
- قد يلزم حد أدنى أو قيم محددة لطول البيانات المُراد تعميتها. مثلًا، مضاعفات 4 أو 8 أو 16 بايت ... إلخ، وعندها تضاف بايتات الحشو لإكمال طول البيانات حتى القيمة اللازمة.
- قد يلزم إضافة عدة بايتات لجعل نهاية الحقلين التاليين تقع عند مضاعفات 4 بايت، وعندها تُضاف بايتات حشو حسب الحاجة لتحقيق ذلك.
- حقل طول الحشو: طوله 8 بت، ويحتوي عدد البايتات المُضافة في قسم الحشو.
- حقل الترويسة التالية: طوله 8 بت، ويحتوي قيمة تُعرِّف نوع الترويسة الموجودة مباشرةً بعد هذه الترويسة.
- حقل قيمة التحقق من السلامة: متغيِّر الطول ويلزم أن يكون طوله من مضاعفات 32 بت، ويُضمُّ قيمة عددية تُحسب في العقدة المصدر من أجل محتويات رزمة البيانات التي لا تتغير خلال عبورها الشبكة. يعاد حساب هذه القيمة في العقدة الوجهة، ولا يمكن الحصول على القيمة نفسِها لحقل التحقق من السلامة إلا إذا كانت محتويات الرزمة هي نفسُها دون تغيير، ومعنى ذلك أنها وصلت من المصدر إلى الوجهة دونَ تلاعبٍ فيها.
بنية الخيارات
[عدل]![](http://upload.wikimedia.org/wikipedia/commons/thumb/4/43/IPv6_option_structure-ar.svg/300px-IPv6_option_structure-ar.svg.png)
يُمكن لترويستان من الترويسات التي تُعرِّفها محددات البروتوكول أن تحمل خياراتٍ مُختلفة العدد والحجم، وهما ترويستا خيارات المسار وخيارات الوجهة. إن بنية خيارات البروتوكول ثلاثية الحقول، وهي تتكون من البنية التالية:[64][65]
- حقل النوع: طوله 8 بت، ويحتوي مُعرِّف رقمي يحدد نوع الخيار.
- حقل الطول: طوله 8 بت، ويحتوي طول الخيار مُقدرًا بالبايت.
- حقل القيمة: مُتغيِّر الطول، وتكون بنيته ومعاني القيم فيها مرتبطة بنوع الخيار.
تُحدد قيمة البتان الأكثر أهمية في حقل النوع سلوك العقدة التي تُعالج الخيار إذا أخفق في التَّعرُّف على نوعه، فإذا كانت قيمتهما 2(00) فعلى العقدة تخطي الخيار واستكمال معالجة الترويسة. وإذا كانت قيمتهما 2(01) فعلى العقدة التخلُّص من الرزمة. وإذا كانت قيمتهما 2(10) فعلى العقدة التخلص من الرزمة والاعتماد على بروتوكول رسائل التحكم للإصدار السادس لإرسال رسالة خطأ يُشير فيها إلى عدم إمكانية التعرف على نوع الخيار، وذلك بغض النظر عن كون مصدر الرزمة عنوان بث فريد الوجهة أو عنوان بث مجموعاتي. أما إذا كانت قيمتهما 2(11) فعلى العقدة تنفيذ ما سبق فقط إذا لم يكن عنوان مصدر الرزمة عنوان بثِّ مجموعاتي.[65] أما البت الثالث من حيث الأهمية، فإن قيمته تحدد فيما إذا كان محتوى الخيار يتغير أثناء انتقال الرزمة عبر الشبكة. فإن كان المحتوى مُتغيرًا، كانت قيمة البت هي 1، وإن كان ثابتًا كانت قيمته 0.[66]
مع أن مُحددات البروتوكول تقدم دليلًا إرشاديًّا لتبيان كيفية تصميم خيارات للإصدار السادس من بروتوكول الإنترنت،[67] إلا أن وثيقة مُحددات البروتكول لا تُعرِّف إلا خيارين اثنين فقط، هما خيار حشو بايتٍ واحد (بالإنجليزية: Pad1 option)، وخيار حشو N بايت (بالإنجليزية: PadN option). ويُستخدمان لمحاذاة نهاية الخيار مع واحدة طول الترويسة، وهي 4 بايت. أي إذا كان طول الخيار مثلًا 11 بايتًا، فيضاف خيار حشو بايت وحيدٍ في النهاية، وإن كان 13 بايتًا يُضاف خيار حشوٍ لثلاث بايتات. وخيار حشو بايت واحد هو الخيار الوحيد الذي لا يتبع بنية الخيارات السابقة، بل يتكون من بايت وحيد صفريّ البتات.[68]
-
بنية خيار حشو بايت واحد
-
بنية خيار حشو N بايت
الوظائف
[عدل]العنونة
[عدل]تعاريف
[عدل]تُعرِّف محددات البروتوكول فضاءً للعناوين، ويبلغ طول العنوان فيه 128 بتًّا، ومعنى ذلك أن الفضاء يضمّ 2128 عنوانًا أي ما يقارب 3.4x1038 عنوانًا.[3][ar 3] تُمنح عناوين الإصدار السادس للمنافذ، لا للعقد، ويمكن للمنفذ أن يستضيف أكثر من عنوان في الوقت نفسه. يدعم الإصدار السادس من بروتوكول الإنترنت ثلاثة أنماط لعنونة المنافذ هي عنونة البث فريد الوجهة، وعنونة البث المجموعاتي وعنونة البث نحو الأقرب، ولا يدعم البروتوكول نمط عنونة البث العام. في عنونة البث فريد الوجهة، يستضيف منفذ ما عنوانًا فريدًا، ويجري توجيه الرزم المُرسلة نحو هذا العنوان إلى المنفذ الذي يستضيفه. أما في عنونة البث المجموعاتي، فتَستضيف مجموعة من المنافذ عنوانًا ما في الوقت نفسه، ويجري توجيه الرزم المُرسلة نحو ذلك العنوان إلى المنافذ التي تستضيفه جميعُها. أما في عنونة البث الأقرب، فتستضيف مجموعة من المنافذ عنوانًا ما في الوقت نفسه، ويجري توجيه الرزم المُرسلة نحو هذا العنوان إلى أقرب منفذ يستضيفه.(5) إذا كان للعقدة منفذٌ وحيدٌ فقط يستضيف عنوان بثٍ فريد الوجهة فقط، يجوز أن يُستعمل العنوان مُعرِّفًا للعقدة.[4]
التمثيل الرياضي
[عدل]![](http://upload.wikimedia.org/wikipedia/commons/thumb/6/62/IPv6_address_terminology-ar.svg/300px-IPv6_address_terminology-ar.svg.png)
يبلغ طول عنوان الإصدار السادس من بروتوكول الإنترنت 128 بتًّا، ويكون البت الواقع في أقصى اليسار هو البت ذو الأهمية العليا. يُكتب عنوان الإصدار السادس باستعمال نظام العد ست العشري، وتُمثَّل كل 4 بتات متتالية بخانة ستة عشرية واحدة تكون قيمتها حسب الجدول التالي:
قيمة البتات الأربعة بنظام العد الثنائي |
القيمة الموافقة بنظام العد ست العشري |
قيمة البتات الأربعة بنظام العد الثنائي |
القيمة الموافقة بنظام العد ست العشري |
---|---|---|---|
0000 | 0 | 1000 | 8 |
0001 | 1 | 1001 | 9 |
0010 | 2 | 1010 | a(6) |
0011 | 3 | 1011 | b |
0100 | 4 | 1100 | c |
0101 | 5 | 1101 | d |
0110 | 6 | 1110 | e |
0111 | 7 | 1111 | f |
![](http://upload.wikimedia.org/wikipedia/commons/thumb/5/5f/IPv6_address_stracture-ar.svg/300px-IPv6_address_stracture-ar.svg.png)
تُسمَّى كل أربع خانات ستة عشرية متتالية رباعيةً (بالإنجليزية: Quartet)،(7) ويُفصل بين كل رباعيتين متتاليتين محرف النقطتين الرأسيتين، أي ":"، وتكون الرباعية الواقعة في أقصى اليسار هي الأعلى أهمية.[69] مثلًا العنوان التالي هو مثال عن عنوان من الإصدار السادس من بروتوكول الإنترنت:
في عناوين البث فريد الوجهة، يتكون كل عنوان من قسمين، هما مُعرِّف الشبكة ومُعرِّف المنفذ. يكون مُعرِّف الشبكة مُشترَكًا بين جميع العناوين التي تنتمي للفضاء الجزئي نفسه، أما مُعرِّف المنفذ فيكون مميزًا لكل منفذٍ على حدة. يُشتق كل عنوان بث فريد الوجهة انطلاقًا من بادئة ما، ويُستعمل طول تلك البادئة لتحديد الحد الفاصل بين مُعرِّف الشبكة ومُعرِّف المنفذ، فإذا كان طول بادئة ما 64 بتًّا، فهذا يعني أن مُعرِّف الشبكة يمتد على أربعٍ وستين بتًّا متتابعًا بدءًا من البت ذي الأهمية العليا وبشكلٍ غير مُنقطع، في حين يمتد مُعرِّف المنفذ على البتات الأربعة والستين المتبقية.[70] تصف وثيقة طلب التعليقات RFC 5952 الممارسات المُتبعة لتمثيل عناوين الإصدار السادس من بروتوكول الإنترنت بالشكل السليم، وتلخص عددًا من المُشكلات التي ترتبط بالمسألة مثل حالة الحروف كبيرة أو صغيرة واستعمال النقطتين الرأسيتين وغير ذلك وتطرح حلولًا لها.[71]
تمثيل العناوين والأقنعة
[عدل]العنوان المُكتمل | العنوان المختصر |
---|---|
2340:0000:0010:0100:1000:abcd:0101:1010 | 2340:0:10:100:1000:abcd:101: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 |
يُمثَّل عنوان الإصدار السادس من بروتوكول الإنترنت بثلاثة طرق:[73][74]
- التمثيل المكتمل: وفيه يكتب العنوان كاملًا بالشكل #:#:#:#:#:#:#:#، وفيه يُمثل الرمز # أربع مراتب ستة عشرية. ومثاله العنوان:0123:4567:89ab:cdef:0123:4567:89ab:cdef.
- التمثيل المُختصر: وفيه تختصر أجزاء من العنوان بالشكل التالي:
- كانت المرتبة الأعلى أهميةً في رباعية ما صفرية لوحدها أو صفرية مع أكثر من مرتبة متتابعة معها، تهمل الأصفار وتُسقط من الكتابة وتكتب المراتب الست عشرية غير الصفرية فقط، فمثلًا الرباعية 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:0:0:0:1234 ولا يكتب 1111::2222::1234. وأمَّا إذا كان طول التتابعين متساويًا، أمكن اختزال أحدهما دون تمييز.
- التمثيل المُختلط: وهو تمثيل يُستعمل في الشبكات التي يستضيف المضيفون فيها عناوين من الإصدارين الرابع والسادس معًا، ويكون شكل العنوان d.d.d.d:#:#:#:#:#:#، حيث يُمثِّل الرمز # رباعيةً مكونة من 4 خانات ست عشرية غير صفرية، وتطبق قواعد الاختصار إذا وجدت خانات صفرية، أمَّا المحرف d فيُمثِّل خانة من خانات عنوان الإصدار الرابع من بروتوكول الإنترنت مكتوبة بالنظام العشري المُنقَّط [الإنجليزية]، ومثال هذا التمثيل العنوان: 1111:0:0:0:0:0:200.100.10.1 والذي يمكن أن يكتب بعد الاختصار بالشكل التالي: 200.100.10.1::1111.
تمثيل البادئات
[عدل]البادئة (بالإنجليزية: Prefix) هي فضاء جزئي من الفضاء الكلي لعناوين البروتوكول، وتُمثَّل كل بادئة بعنوان يُسمى عنوان البادئة. ويتشابه تمثيل البادئات في الإصدار السادس من بروتوكول الإنترنت مع تمثيلها في الإصدار الرابع، والذي أُقِرَّ بعد اعتماد آلية التوجيه غير الصنفي بين النطاقات.[75] تتكون كل بادئة من جزئين، هما عنوان من الإصدار السادس من بروتوكول الإنترنت وطول البادئة، أي عدد البتات فيها، ويكون شكل البادئة:[76]
يمكن اختصار العنوان الموجود في البادئة وفقًا لقواعد اختصار عناوين الإصدار السادس نفسها. فمثلًا، ما سيأتي هو أمثلة عن بادئات مكتوبة بشكل صحيح:[76]
بنى العناوين وفقًا لنمط التوجيه
[عدل]
أنماط التوجيه |
---|
يُعرِّف الإصدار السادس من بروتوكول الإنترنت فضاءً يضمُّ 2128 عنوانًا فيه، ويدعم ثلاثة أنماط من العنونة هي العنونة هي عنونة البث الفريد الوجهة وعنونة البث المجموعاتي وعنونة البث نحو الأقرب.[4] يُخصص فضاء محجوز للبث المجموعاتي، ويُحجز فضاء خاص أيضًا لعناوين البث فريد الوجهة الوصلة المحلية، وفيما يخصص العنوان الصفري ليكون العنوان غير المُحدد والعنوان الذي يليه ليكون عنوان الحلقة العكسية، وفيما خلا ذلك، فما تبقى من الفضاء مُخصص لفضاء عناوين البث فريد الوجهة العالمي. ويبين الجدول التالي العناوين المحجوزة والأفضية الجزئية في الإصدار السادس من بروتوكول الإنترنت:[77]
الاسم | البادئة (طول البادئة [بت]) | تمثيل الفضاء |
---|---|---|
العنوان غير المُحدد | 0 ... 00 (128) |
128/::
|
عنوان الحلقة العكسية | 1 ... 00 (128) |
1/128::
|
فضاء البث المجموعاتي | 11111111 (8) |
ff00::/8
|
فضاء البث فريد الوجهة في الوصلة المحلية | 1111111010 (10) |
fe80::/10
|
فضاء البث فريد الوجهة العالمي | كل ما تبقى من الفضاء |
يجب الانتباه إلى أن عناوين البث نحو الأقرب تقتطع من أي فضاء من عناوين البث فريد الوجهة، لذلك لا يمكن التمييز بين عناوين الفضاءين رقميًَّا، بل وفقًا لبنية العنوان ووظيفته.[77]
عناوين البث فريد الوجهة
[عدل]عناوين البث فريد الوجهة هي العناوين التي تُمّيز منفذًا محددًا. إذا كان عنوان وجهة رزمة ما هو عنوان بث فريد الوجهة، فستُوجَّه الرزمة نحو المنفذ الذي يستضيف هذا العنوان. تمتاز عناوين هذا الفضاء بإمكانية تجميعها معًا وتمثيلها كأفضية جزئية باستعمال تدوين البادئة بشكل مُشابه لتمثيل الأفضية الجزئية في الإصدار الرابع من بروتوكول الإنترنت.[77]
توجد أنواع عديدة لعناوين الفضاء فريد الوجهة منها، هي:
- العنوان غير المُحدد (بالإنجليزية: The Unspecified Address): هو العنوان الصفريّ، أي 0:0:0:0:0:0:0:0 أو اختصارًا ::. يُستعمل للدلالة إلى عدم استضافة المنفذ لعنوان من الإصدار السادس من بروتوكول إنترنت رغم وجود دعم للبروتوكول فيه، لذلك لا يجب أن يُمنح هذا العنوان لأي منفذ. لا يُستعمل هذا العنوان كعنوان وجهة لرزم البيانات، ويلزم أن تتخلص المُوجِّهات أي رزمة مُوجَّهة نحو هذا العنوان.[78]
- عنوان الحلقة العكسية (بالإنجليزية: The Loopback Address): وهو العنوان 0:0:0:0:0:0:0:1 أو اختصارًا 1::، ويُمكن أن يستخدم من قبل أي عقدة لإرسال رزم بيانات إلى نفسها، لذلك لا يجب أن يُمنح هذا العنوان لأي منفذ مادي. لا يُستعمل هذا العنوان كعنوان مصدر للرزم التي ستغادر عقدة ما، ولا يجب أن تُوجَّه الرزم التي تكون وجهتها عنوان الحلقة العكسية نحو خارج العقدة. ويلزم أن تتخلص الموجهات أي رزمة موجهة نحو عنوان الحلقة العكسية.[78]
- عناوين البث فريد الوجهة العالمي (بالإنجليزية: Global Unicast Address): وتُستخدم لعنونة منفذ ما على الإنترنت بشكلٍ فريدٍ على مستوى العالم. يتكون العنوان من ثلاثة حقول: حقل بادئة التوجيه العالمية، وهي تمنح للموقع الذي يُشغل المنفذ بحسب هرمية تحصيص رباعية المستويات تديرها هيئة أرقام الإنترنت المُخصصة، وحقل مُعرف الشبكة الجزئية والذي يَضبطه مشغلو الموقع، حيث يوجد المنفذ، وذلك بهدف تجزئة الفضاء الممنوح إلى أفضية جزئية أصغر حجمًا لأغراض إدارية أو تنظيمية.[78]
- في عناوين البث فريد الوجهة العالمية التي لا تكون قيمة البتات ذات الأهمية العليا فيها 2(000)، يكون مجموع طولي حقلي بادئة التوجيه العالمية ومُعرِّف الشبكة الجزئية 64 بت، ما يترك 64 بتًّا لمُعرف المنفذ، وبهذا تتوافق بنية هذه العناوين مع آلية التهيئة الذاتية الآلية. أما العناوين التي تكون قيمة البتات ذات الأهميةً العليا فيها 2(000) فهي لا تُلزَم بالبنية السابقة.[79] وفي ما يأتي مثالٌ عن هذا العنوان: 1::2001:1111:2222:3333
- عناوين البث فريد الوجهة في الوصلة المحلية (بالإنجليزية: Link-Local Unicast Address): ويشغل الفضاء fe80::/10،[80] تُستخدم عناوين هذا الفضاء على مستوى الوصلة المحلية فقط، وهي مصممة لتخدم أغراضًا مثل التهيئة الآلية للعنوان واكتشاف الجيران. لا يجب على المُوجِّهات توجيه أي رزمة بيانات يكون عنوان مصدرها أو وجهتها عنوان وصلة محلية.[81]
- يتكون عنوان الوصلة المحلية من ثلاثة حُقول: الحقل الأول هو مُعرِّف فضاء عناوين الوصلة المحلية، وطوله 10 بتات وقيمته 2(1111111010)، أما الحقل الثاني فهو حقل صفري يبلغ طوله 54 بتًّا، والحقل الثالث هو حقل مُعرف المنفذ، ويُستخدم لتمييز المنفذ بشكل فريد على مستوى الوصلة المحلية.[81] وفي ما يأتي مثالٌ عن هذا العنوان: fe80::1ff:fe01:101
- عناوين البث فريد الوجهة الفريد المحلي (بالإنجليزية: Unique Local IPv6 Unicast Addresses): حُجر له الفضاء fc00::/7،[82] ويُستخدم من أجل عنونة منفذ بشكل فريد على المستوى العالمي، ولكن من أجل إنشاء اتصالات محلية فقط، ولذلك لا يمكن توجيه الرزم المعنونة بهذه العناوين خارج الموقع الذي ولِّدت فيه.[83]
- يتألف العنوان الفريد المحلي من 5 حقول، أولها هو حقل البادئة وطوله 7 بتات وقيمته هي 2(1111110) دائمًا، ويليه بت المحلية، ويُضبط إلى القيمة 1 دائمًا للإشارة إلى أن العنوان قد وُلِّد محليًّا،(8) ثُمَّ حقل المُعرِّف العالمي وطوله 40 بتًّا، وهو مُعرِّف فريد على مستوى العالم يضبط محليًّا إلى قيمة عشوائية، ثُمّ حقل مُعرِّف الشبكة الجزئية طوله 16 بت، وهو حقل مخصص لمديري الشبكة لإتاحة إمكانية إنشاء شبكات جزئية، وأخيرًا مُعرِّف المنفذ وطوله 64 بتًّا، ويميز كل منفذ على حدته بشكل فريد.[84] وفي ما يأتي مثالٌ عن هذا العنوان: مرجع fdf8:f53b:82e4::53
- عناوين البث فريد الوجهة المحلي في الموقع (بالإنجليزية: Site-Local Unicast Address): وهو صنف مُبطَل من عناوين البث فريد الوجهة.[85] طُوِّر في الأصل ليَخدُم غرض العنونة داخل موقع ما دون الحاجة لبادئات عالمية. حُجر له الفضاء fec::/10،[82] كانت بنية هذه العناوين مكونة من ثلاثة حقول: الحقل الأول هو معرف فضاء العناوين المحلية في الموقع، وطوله 10 بتات وقيمته 2(1111111011)، أما الحقل الثاني فهو مُعرِّف الشبكة الجزئية، ويضبطه مشرفو الموقع حسب الحاجة، وأما الحقل الثالث فهو مُعرِّف المنفذ ويبلغ طوله 64 بتًّا.[81] وفي ما يأتي مثالٌ عن هذا العنوان: fec0::1234:5678:9abc
- عناوين البث فريد الوجهة التي تتضمن عناوين من الإصدار الرابع: يوجد عنوانان من عناوين البث فريد الوجهة في الإصدار السادس يحملان في البتات الاثنين والثلاثين ذات الأهمية الدنيا عناوين من الإصدار الرابع من بروتوكول الإنترنت وهما:
- عناوين البث فريدة الوجهة المُتوافِقة مع الإصدار الرابع (بالإنجليزية: IPv4-Compatible Unicast Address): عُرِّفت هذه العناوين في الأصل لتساهم في دعم عملية الانتقال من استعمال الإصدار الرابع إلى الإصدار السادس من بروتوكول الإنترنت. يتكون هذا العنوان بدءًا من الخانة الأكثر أهمية من 80 صفرًا يليها عنوان الإصدار الرابع من بروتوكول الإنترنت الذي يلزم أن يكون فريدًا عالميًّا.[79]
- تُستخدم الطريقة الهجينة لتمثيل هذه العناوين. أبطلت طريقة الانتقال التي تستعمل هذه العناوين، ولذلك لم تعد هذه العناوين قيد الاستخدام.[79] وفي ما يأتي مثالٌ عن هذا العنوان: 200.100.10.1::
- عناوين البث فريدة الوجهة المُقترنة مع الإصدار الرابع (بالإنجليزية: IPv4-Mapped Unicast Address) وتستعمل لحمل عنوان الإصدار الرابع من بروتوكول الإنترنت الذي تستضيفه العقدة التي تدعم الإصدار السادس أيضًا.[79] وصفت طريقة استعمال هذا العنوان في وثيقة طلب التعليقات RFC 4038،[86] وهو يتكون من ثلاثة حقول بدءًا من الخانة الأكثر أهمية هي 80 صفرًا متتاليًّا في الحقل الأول، يليها 16 واحدًا متتاليًّا في الحقل الثاني، ثُمَّ عنوان الإصدار الرابع من بروتوكول الإنترنت.[81] وفي ما يأتي مثالٌ عن هذا العنوان: ffff:192.0.2.47::
-
بنية عنوان البث فريد الوجهة العالمي.
-
بنية عنوان البث فريد الوجهة في الوصلة المحلية.
-
بنية عنوان البث فريد الوجهة في الفريد المحلي.
-
بنية عنوان البث فريد الوجهة المحلي في الموقع.
-
بنية عنوان البث فريد الوجهة المُتوافِق مع الإصدار الرابع من بروتوكول الإنترنت.
-
بنية عنوان البث فريد الوجهة المُقترن مع الإصدار الرابع من بروتوكول الإنترنت.
عناوين البث نحو الأقرب
[عدل]عنوان البث نحو الأقرب في الإصدار السادس من بروتوكول الإنترنت (بالإنجليزية: IPv6 anycast address) هو عنوان بث فريد الوجهة يُمنح لأكثر من منفذ في الوقت عينه، وغالبًا ما تكون في هذه المنافذ في عقد متمايزة. إذا أُرسلت رزمة بيانات ما إلى عنوان بث نحو الأقرب، فإنها تُرسل إلى أقرب(5) عقدة تستضيف ذلك العنوان. تُحصص عناوين البث نحو الأقرب من فضاء البث فريد الوجهة، من غير أي قيود إضافية، لذلك لا يمكن تمييز عناوين البث نحو الأقرب عن عناوين البث فريد الوجهة رياضيًّا. بعبارة أخرى، إذا مُنح عنوان بث فريد الوجهة إلى أكثر من منفذ في الوقت عينه فإنَّه يًصبح عنوان بثٍّ نحو الأقرب، ويجب تهيئة العقد بشكل صريح لتكون على دراية بذلك.[87]
يتكون عنوان البث نحو الأقرب من قسمين، يمُثل الأول بادئة الشبكة الجزئية، وهي مُعرِّف رقمي طوله n بت، يُحدد جزءًا من الطوبولوجيا حيث توجد جميع العقد التي تستضيف عناوين بثٍ نحو الأقرب، أما القسم الآخر من العنوان فهو ذو قيمة صفرية.[87]
يَلزَم أن تميير المُوجِّهات عنوان البث نحو الأقرب ببند فريد في جداول التوجيه ضمن جزء الطوبولوجيا الذي توجد فيه العناوين، ولكن خارج هذا الجزء، يمكن تجميع العنوان مع مسارات أخرى ولا داعٍ لتمييزه ببند فريد. توجد حالة خاصة يلزم أن يكون فيه بند عنوان البث نحو الأقرب فريدًا على مستوى الإنترنت كلها ولا يجوز تجميع هذا البند مع أي بند آخر، وتحصل هذه الحالة عند استعمال بادئة غير مُحدَدة طوبولوجيًّا (بالإنجليزية: null prefix)، أي أنها يمكن أن تمنح للمنافذ في أي موقع في الإنترنت.[88]
عناوين البث المجموعاتي
[عدل]![](http://upload.wikimedia.org/wikipedia/commons/thumb/c/c1/IPv6_multicast_address_stracture-ar.svg/300px-IPv6_multicast_address_stracture-ar.svg.png)
عنوان البث المجموعاتي هو مُعرِّف رقمي يُميِّز مَجموعة محددة من المنافذ التي تستضيفه. إن إرسال أي رزمة بيانات إلى عنوان بث مجموعاتي ما سيؤدي إلى توجيهها إلى جميع أعضاء المجموعة المميزة بذلك العنوان.[89] يتكون عنوان البث المجموعاتي من أربعة حقول هي وفقًا لترتيب ورودها من الخانة الأعلى أهمية:[88]
- حقل بادئة البث المجموعاتي: طوله 8 بت، ويحتوي القيمة 2(11111111) أو 16(FF)، وهي تميز عناوين فضاء البث المجموعاتي جميعها.
- حقل الأعلام: طوله 4 بت، تُثبَّت قيمة البت الأعلى أهمية فيه إلى القيمة 0، وأما البتات الثلاثة اللاحقة في وفقًا لترتيب ورودها من الخانة الأعلى أهمية:
- علم الالتقاء: ويحدد فيما إذا كان العنوان يتضمن عنوان نقطة الالتقاء أم لا، فهو كذلك إذا كان واحديًّا، أما إذا كان صفريًّا فهو بخلاف ذلك.[90]
- علم البادئة: ويحدد فيما إذا كان منح العنوان قد جرى على أساس بادئة الشبكة فريدة الوجهة حيث سيُستضاف العنوان، فإذا كان العلم واحديًّا فإن العنوان قد منح على أساس البادئة وإلا فإنه لم يُمنح على ذلك الأساس.[91]
- علم الديمومة: وإذا كان صفريًّا فإن العنوان ممنوح بشكل دائم من قبل أيانا ومعروفٌ في الإنترنت كاملةً، أما إذا كانت قيمته واحدية، فالعنوان ليس دائمًا ويكون ذا معنى في مجال مُحدد بحقل المجال.[88]
- حقل المجال: طوله 4 بت، ويضم رمزًا يحدد المجال الطوبولوجي الذي تمتد عليه المجموعة كما في الجدول التالي:[92]
قيمة حقل المجال بنظام العد الثنائي |
اسم المجال | امتداد المجال |
---|---|---|
0000 | محجوز | - |
0001 | مجال المنفذ | يشمل هذا المجال منفذًا واحدًا في عقدة واحدة، ويستعمل هذا المجال في تطبيقات الحلقة العكسية. |
0010 | مجال الوصلة المحلية | يمتد المجال ليغطي الشبكة المحلية بشكلٍ متوافق مع شبكة عناوين البث فريد الوجهة المُستخدَمة محليًّا. |
0011 | محجوز | - |
0100 | مجال الإشراف المحلي | يمتد المجال على جزء من الشبكة يقوم مشرفوها بتحديده، وهو أصغر مجال يمكن تحديده إشرافيًّا. |
0101 | مجال الموقع المحلي | يمتد المجال ليغطي موقعًا محليًّا واحدًا، قد يشمل عدة شبكات محلية، ولكنَّها تعود لمنظمة واحدة. |
0100 | مجال المنظمة المحلي | يمتد المجال على عدة مواقع محلية لمنظمة واحدة. |
1110 | المجال العالمي | يشمل المجال الإنترنت كاملة. |
1111 | محجوز | - |
- تكون قيم المجال غير المحجوزة وغير المُخصصة لمجال معين متاحة للاستخدام من قبل مشرفي الشبكة المحلية لتعريف مجالات فرعية تلائم أغراضهم الخاصة.[93]
- حقل مُعرف المجموعة، وطوله 112 بت، ويضم مُعرفًا رقميًّا يميز المجموعة ضمن المجال المُحدد بحقل المجال. توجد بنى عناوين بث مجموعاتي أكثر تخصصًا، ومنها مثلًا ما تُعرِّفه الوثيقة RFC 3306،[94] وفيه يُقسم مُعرف المجموعة إلى ثلاثة أربعة حقول تتضمن مُعرِّفًا للمجموعة بطول 32 بت فقط، وحقلًا لبادئة شبكة البث فريد الوجهة الذي يُمنح العنوان على أساسها. وتصف الوثيقة RFC 7371 بنى عناوين البث المجموعاتي في الإصدار السادس وحالاتها المُختلفة ومعاني كلٍ منها.[95]
أفضية محجوزة
[عدل]توجد أفضية عناوين محجوزة مخصصَّة لبروتوكولات محددة أو لاستعمالات خاصة، ولا يجوز استعمال عناوين من هذه الأفضية من أجل عنونة المُضيفين في الإنترنت. تشرف هيئة أرقام الإِنترنت المُخصَّصة على حفظ وإدارة هذه الأفضية.[96]
أفضية البث فريد الوجهة والبث نحو الأقرب
[عدل]فضاء العناوين | تاريخ الحجز | ملاحظات | مرجع |
---|---|---|---|
128/:: | فبراير 2006 | العنوان غير المُحدد | [78] |
1/128:: | فبراير 2006 | عنوان الحلقة العكسية | [78] |
ff9b::/96 | أكتوبر 2010 | مخصص لمترجمات العناوين بين الإصدارين الرابع والسادس | [97] |
ffff:0:0/96:: | فبراير 2006 | فضاء العناوين المقترنة مع الإصدار الرابع | [78] |
64/::100 | يونيو 2012 | بادئة الاستبعاد (بالإنجليزية: Discard Prefix)، وهي بادئة تستعمل في عملية التوجيه والترشيح للتخلص من رزم البيانات | [98] |
23/::2001 | سبتمبر 2000 | مخصص لعملية تطوير إرشادات لمنح أفضية الإصدار السادس من بروتوكول الإنترنت | [99] |
32/::2001 | فبراير 2006 | مخصص لدعم تقنية تيريدو للانتقال من الإصدار الرابع نحو الإصدار السادس من بروتوكول الإنترنت | [100] |
1/48::2001:1 | أكتوبر 2015 | عنوان مُخصص للبث نحو الأقرب لبروتوكول التحكم بالمنافذ [الإنجليزية] | [101] |
2/48::2001:1 | فبراير 2017 | عنوان مُخصص للبث نحو الأقرب بروتوكول تخطي الترجمة باستعمال المُرحلات [الإنجليزية] TURN | [102] |
48/::2001:2 | أبريل 2008 | فضاء مخصص لعملية المقارنة المرجعية | [103] |
32/::2001:3 | ديسمبر 2014 | فضاء مخصص للإنشاء الآلي لأنفاق البث المجموعاتي | [104] |
48/::2001:4:112 | ديسمبر 2014 | فضاء مخصص لمشروع النظام المستقل رقم 112 (بالإنجليزية: AS112 project) | [105] |
28/::2001:10 | أبريل 2007(9) | فضاء مخصص لبادئة معرفات التجزئة المُعمَّاة المتراكبة القابلة للتوجيه، المعروفة اختصارًا بالاسم الرمزي: أوركيد ORCHID | [106] |
28/::2001:20 | يوليو 2014 | فضاء مخصص للإصدار الثاني لبادئة معرفات التجزئة المُعمَّاة المتراكبة القابلة للتوجيه، المعروفة اختصارًا بالاسم الرمزي: أوركيد 2 | [107] |
2001:0db8::/32 | يوليو 2004 | فضاء مخصص لعملية التوثيق | [108] |
16/::2002 | فبراير 2001 | فضاء مخصص لدعم تقنية 6 إلى 4 (بالإنجليزية: 6to4) للانتقال من الإصدار السادس نحو الإصدار الرابع من بروتوكول الإنترنت | [109] |
fc00::/7 | أكتوبر 2005 | مخصص لفضاء عناوين البث فريد الوجهة الفريد المحلي | [110] |
fe80::/10 | أكتوبر 2005 | مخصص لفضاء عناوين البث فريد الوجهة في الوصلة المحلية | [81] |
فضاء البث المجموعاتي
[عدل]تدير أيانا فضاء عناوين البث المجموعاتي في الإصدار السادس من بروتوكول الإنترنت، وهو الفضاء الذي يتحدد بالبادئة ff00::/8.[Web 7] توجد مجموعة من العناوين المُعرَّفة المحجوزة التي لا يجب منحها لأي مجموعة في شبكات الإصدار السادس، وهي:[111]
- جميع العناوين ذات البنية ff0#:0:0:0:0:0:0:0، وعددها 16 عنوانًا، حيث # هي مرتبة ستة عشرية تأخذ أي قيمة من المجال {9 .. 1,2} أو{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 من أجل مجموعة كل الموجهات التي تشغل بروتوكول التوجيه الداخلي المحسن بين البوابات وغير ذلك.[Web 7]
عناوين ملزمة
[عدل]تميّز معايير الإصدار السادس من بروتوكول الإنترنت بين المُضيف والمُوجِّه، فالموجه هو عقدة تُوجِّه رزم بيانات لم تولدها للإصدار السادس من بروتوكول الإنترنت. أمَّا المُضيف فهو أي عقدة ما خلا الموجهات.[38] بناءً على ذلك، يلزم على كل مُضيف أن يكون قادرًا على تمييز العناوين التالية بصفتها معرفاتٍ ذاتية:[112]
- عنوان محلي في الوصلة من أجل كل منفذ من منافذه.
- عنوان الحلقة العكسية.
- أي عناوين بث فريد الوجهة أو بث نحو الأقرب جرى تهيئته بها، سواء كانت التهيئة يدويةً أو آليةً.
- جميع عناوين البث المجموعاتي المحجوزة للعقد.
- عنوان البث المجموعاتي الخاص بالتماس العقدة من أجل كل عنوان بث فريد الوجهة أو بث نحو الأقرب.
- أي عناوين بث مجموعاتي تُمثل مجموعات انضم المُضيف إليها.
أمَّا المُوجِّه، فيلزم أن يميز العناوين السابقة التي يميزها المضيف، وأيضًا العناوين التالية، بوصفها مُعرفات ذاتية:[112]
- عناوين البث نحو الأقرب للشبكات الجزئية على جميع المنافذ التي هُيِّئت لتعمل بوصفها منافذَ للمُوجه.
- جميع عناوين البث نحو الأقرب التي جرت تهيئة المُوجِّه بها.
- جميع عناوين البث المجموعاتي المحجوزة للمُوجِّهات.[Web 7]
التهيئة الذاتية الآلية
[عدل]التهيئة الذاتية الآلية في الإصدار السادس من بروتوكول الإنترنت أو التهيئة غير المركزية الآلية (بالإنجليزية: IPv6 Stateless Address Autoconfiguration) هي آلية تحدد الخطوات التي يتخذها مضيفو الإصدار السادس من أجل تهيئة منافذهم ذاتيًّا بعناوين وصلة محلية أو عناوين عالمية باستعمال معرفات المنفذ المولدة محليًَّا ومعلومات البادئات التي يحصل المُضيف عليها من إعلانات الموجهات في الشبكة المحلية، وتشمل هذه الآلية أيضًا إجراءاتٍ مُحددة لاكتشاف الاستخدام المتعدد للعنوان لضمان فرادته على مستوى الوصلة المحلية. لا تتطلب التهيئة الذاتية أي إعداد يدوي في المضيفين، وإعداد بسيطًا، وقد لا يكون ضروريًّا، في الموجهات وهي لا تحتاج لوجود مُخدِّمات. يمكن للمضيف، في غياب الموجهات، أن يولد عنوانًا محليًّا في الوصلة ذاتيًّا دون أي تدخل خارجي.[113]
تحصل عملية التهيئة الذاتية الآلية في المنافذ التي تدعم الإصدار السادس من بروتوكول الإنترنت في أربع حالات هي: تشغيل المنفذ بعد إقلاع النظام، وإعادة تشغيل المنفذ بعد إخفاق سابق له، واتصال المنفذ مع شبكة ما للمرة الأولى، وإعادة تفعيل المنفذ بعد تعطيل سابق لأسباب إشرافية.[114] تحصل عملية التوليد الذاتية الآلية لعنوان محلي في الوصلة باتباع الخطوات التالية:[115]
- تكون بادئة العنوان هي fe80::/10، وتحجز البتات العشرة الأعلى أهمية.
- يُملأ سائر العنوان بالأصفار.
- يحسب مُعرِّف المنفذ وليكن طوله N بت، وقد يحتوي عنوان مادي موجود في المنفذ نفسه، ويكون طوله 64 بت في الغالب.
- بدءًا من الخانة الأقل أهمية في العنوان يُستبدل N صفرًا في العنوان بمُعرف المنفذ.
يمكن أيضًا أن تستخدم الآلية السابقة نفسها في تشكيل عناوين فريدة عالميًّا بشكل ذاتي وآلي. ولتحقيق ذلك، يلزم أن يحصل المُضيف على البادئة الفريدة عالميًّا باستعمال بروتوكول اكتشاف الجيران سواء عن طريق إرسال رسالة التماس للمُوجهات الموجودة في الشبكة المحلية أو انتظار رسائل الإعلان التي تُرسلها بشكل دوري. بعد ذلك، يستعمل المضيف البادئة التي حصل عليها في الخطوة الأولى من الخوارزمية السابقة بدلًا من بادئة فضاء العناوين المحلية في الوصلة fe80::/10، ثُمَّ يتابع تنفيذ بقية الخطوات كما وردت.[116]
في ما يخص مُعرفات المنافذ، فيمكن توليدها باستعمال العناوين المادية كما في آلية توليد المُعرّف الفريد المُوسّع (EUI) المطورة من قبل معهد مهندسي الكهرباء والإلكترونيات،[117] أو تُولَّد بصورة مستقلة العناوين المادية باعتماد خوارزمية موصوفة في وثيقة طلب التعليقات RFC 7217 وتكون المُعرفات الناتجة عنها آمنة ومستقرة وفريدة على المستويين المحلي والعالمي.[118]
إدارة فضاء العناوين: التحصيص والمنح
[عدل]![](http://upload.wikimedia.org/wikipedia/commons/thumb/c/c9/IPv4_address_assignment_hierarchy-ar.svg/300px-IPv4_address_assignment_hierarchy-ar.svg.png)
![](http://upload.wikimedia.org/wikipedia/commons/thumb/f/f4/IPv6_Prefix_Assignment_Example-ar.svg/300px-IPv6_Prefix_Assignment_Example-ar.svg.png)
بشكل مشابه للإصدار الرابع من بروتوكول الإنترنت، تُشرف شركة الإنترنت للأرقام والأسماء الممنوحة المعروفة اختصارًا بالاسم آيكان، عبر هيئة أرقام الإنترنت المُخصصة على تحصيص فضاء عناوين الإصدار السادس من بروتوكول الإنترنت، وتجري عملية التحصيص بحسب هرميةٍ مكونةٍ من المستويات الأربعة نفسها. في هذه الهرمية، يقع العميل الذي يحصل على فضاء جزئي مُخصص في قاعدة هرم التحصيص وهو المستوى الرابع والأخير في الهرمية، أمّا المستويات الثلاثة الأولى، فهي مرتبة بدءًا من رأس الهرم كما يلي: هيئة أرقام الإنترنت المُخصصَة، ثًمَّ سجلات الإنترنت الإقليمية ويليها سجلات الإنترنت المحلية.[119]
وضع آيكان سياسةً تُنظِّم عملية التحصيص، تُلزَم أيانا بموجبها على تقديم حصص من العناوين لسجلات الإنترنت الإقليمية تكفي حاجتها 18 شهرًا على الأقل، على أن يكون طول البادئة الأدنى الذي تحصصه أيانا هو البادئة 12/.[Web 8] توفِّر عملية التهيئة الذاتية الآلية (بالإنجليزية: Stateless address autoconfiguration اختصاراً SLAAC) وسيلةً لعنونة المُضيفين آليًَّا باستعمال العناوين المحليَّة دون الحاجة لتدخلٍ يدويٍّ من قبل مدير الشبكة، حيث يجري ملء قسم مُعرِّف المنفذ اعتمادًا على مُعرِّفات المنافذ.[115] تحدد وثيقة طلب التعليقات RFC 4291 العلاقة بين طول البادئة ومُعرِّف المنفذ في عنوان الإصدار السادس الذي يبلغ طوله 128 بتًّا، فإذا كان طول البادئة هو n بت، فإن طول مُعرِّف المنفذ الملائم لعملية التهيئة الذاتية الآلية سيكون (128-n) بتًّا،[70] وتدعم الشركات المُصنِّعة لبطاقات الشبكة هذا المعيار أو تقدِّم حلولًا متوافقة معه، مثل حل المُعرِّف الفريد المُوسَّع الذي وضعه معهد مهندسي الكهرباء والإلكترونيات لإيجاد التوافق مع العنوان المادي في الإيثرنت الذي يبلغ طوله 48 بتًّا فقط.[117] أي يُستحسن أن يكون طول البادئة النهائي هو 64 بتًّا لإتاحة الفرصة لعملية التهيئة الذاتية الآلية
نظريًَّا، خلال عمليتي التحصيص والتخصيص(10) لعناوين الإصدار السادس من بروتوكول الإنترنت، يكون طول البادئة محصورًا بين البادئة 12/ وهو الطول الأدنى الذي تحصصه أيانا، والبادئة 64/، وهو الطول الأقصى اللازم لدعم عملية التهيئة الذاتية الآلية. عمليًَّا، حصصت أيانا بادئات بأطوال 23/ و12/ لسجلات الإنترنت الإقليمية[Web 9] التي قدمت بدورها حلولًا لمزودات الخدمة أو للعملاء على حد سواء، لمنح أفضية جزئيَّة متنوعة الأحجام ذات بادئات لا يتجاوز طولها البادئة 64/، وعلى سبيل المثال، يَدعم مركز تنسيق شبكة الإنترنت الأوروبي (RIPE NCC)، وهو سجل إنترنت إقليمي، حصصًا لأفضية جزئية ذات بادئات يتراوح طولها بين البادئتين 32/ و64/، ويشير إلى أن الأطوال الأكثر شعبية هي للبادئتين 48/ و56/ وهي تضم على التوالي: 65,536 و256 شبكة جزئية مُحددة بالبادئة 64/.[Web 10]
التجزئة
[عدل]![](http://upload.wikimedia.org/wikipedia/commons/thumb/4/42/IPv6_CIDR_table-ar.svg/300px-IPv6_CIDR_table-ar.svg.png)
![](http://upload.wikimedia.org/wikipedia/commons/thumb/f/f0/Subnet_Identifier_Boundaries_in_IPv6-ar.svg/300px-Subnet_Identifier_Boundaries_in_IPv6-ar.svg.png)
يُقسّم مجال فضاء العناوين في الإصدار السادس من بروتوكول الإنترنت إلى مجموعة من الأفضية الجزئية بحسب الغرض من الاستخدام.[77] وتدير هيئة أرقام الإنترنت المُخصصة عملية تحصيص الأفضية، ومنها عملية تحصيص فضاء عناوين البث فريد الوجهة، وفيها تجري عملية منح العناوين الفريدة عالميًّا على أساس جغرافي، وفق بنية هرمية تسمح باستعمال تقنيات التوجيه غير الصنفي بين النطاقات لاختزال عناوين الأفضية، والغرض من ذلك استقرار جداول التوجيه على المستوى العالمي، تخصص هيئة أرقام الإِنترنت المُخصَّصة أفضية عناوين لسجلات الإنترنت الإقليمية، عن طريق منحها بادئات بطول 23 بت.[Web 11] بعد ذلك، يقوم كل سجل إنترنت إقليمي بتجزئة فضاء العناوين إلى أفضية عناوين جزئية تمنح لمزودات الخدمة، وقد تحصل عملية المنح على أكثر من مستوى، مثل منح فضاء عناوين لمزود خدمة وطني ليقوم بتجزئته إلى أفضية أصغر تمنح لمزودات الخدمة المحلية.[Web 12]
يحصل المُشتركون على أفضية عناوين جزئية من مزودات الخدمة المحلية، وتكون البادئة عادة بطول 48 بت، في الغالب الأعم يقتطع مديرو الشبكات قسمًا يبلغ طوله 16 بت من مُعرف المنفذ، ويُنشؤون قسمًا جديدًا هو مُعرّف الشبكة الجزئية الذي يُضاف إلى البادئة فيصبح طولها النهائي 64 بت، ويترك ذلك 64 بت لمُعرّف المنفذ، وهو طول ملائم لآلية توليد المُعرّف الفريد المُوسّع.[120]
إن التجزئة في الإصدار السادس من بروتوكول الإنترنت تتشابه من حيث الآلية الرياضية مع التجزئة في الإصدار الرابع، لكنها تختلف من حيث الغاية، فهي تهدف إلى تنظيم استعمال فضاء العناوين بطريقة متوافقة مع آلية التوجيه، ولا تستخدم لتحديد حجم محدد من أفضية العناوين كما في الحالة في الإصدار الرابع، فعدد العناوين المتاحة في شبكة جزئية واحد من الإصدار السادس طول بادئتها 64 بت، يبلغ المليارات، وهو بحد ذاته، أكبر من كامل فضاء عناوين الإصدار الرابع من بروتوكول الإنترنت.[121]
يتكون عنوان الإصدار السادس من بروتوكول الإنترنت من 128 بت، ويكتب بنظام العد الست عشري على شكل عدد مكوّن من 32 مرتبة ست عشرية، ويجري تجميع هذه المراتب ضمن رباعيات عددها 8 يضم كل منها 4 مراتب ست عشرية أو 16 بت.[69] عند تجزئة فضاء عناوين من الإصدار السادس، يجري اقتطاع قسم من مُعرّف المنفذ وإنشاء قسم جديد هو معرف الشبكة الجزئية، يمكن وفقًا لموقع نهاية مُعرّف الشبكة الجزئية ضمن العنوان التمييز بين الحالات التالية:
- مُعرّف الشبكة الجزئية ينتهي عند حدود إحدى المجموعات الرباعية، ويعني ذلك أن نهاية المُعرّف تكون عند أحد البتات ذوات الفهارس {15,31,47,63,79,95,111,127}.
- مُعرّف الشبكة الجزئية ينتهي عند حدود إحدى المراتب الست عشرية ضمن مجموعة رباعية، وتوجد 3 حالات ممكنة في كل مجموعة رباعية، مثلًا في المجموعة الأولى هي البتات ذات الفهارس {3,7,11} وفي الثانية {19,23,27} وهكذا..
- مُعرّف الشبكة الجزئية ينتهي عند حدود أحد البتات ضمن خانة ست عشرية داخل مجموعة رباعية، وتوجد 3 حالات ممكنة في ضمن كل خانة ست عشرية، مثلًا في الخانة الست عشرية الثانية تكون الحدود الممكنة عند البتات ذات الفهارس {4,5,6} وفي الخانة الست عشرية الثالثة عند البتات ذات الفهارس {8,9,10} وهكذا.(11)
أمثلة عن التجزئة في الإصدار السادس من بروتوكول الإنترنت:
-
التجزئة من أجل عدد محدد لأفضية عناوين الشبكات الجزئية، حالة معرف الشبكة الجزئية ينتهي عند حدود المجموعة الرباعية.
-
التجزئة من أجل عدد محدد لأفضية عناوين الشبكات الجزئية، حالة معرف الشبكة الجزئية ينتهي عند حدود مرتبة ست عشرية.
-
التجزئة من أجل حجم محدد لأفضية عناوين الشبكات الجزئية، حالة معرف الشبكة الجزئية ينتهي عند حدود بت ضمن مرتبة ست عشرية.
-
التجزئة من أجل طول محدد لقناع الشبكات الجزئية، حالة معرف الشبكة الجزئية ينتهي عند حدود مرتبة ست عشرية.
التقطيع
[عدل]![](http://upload.wikimedia.org/wikipedia/commons/thumb/5/55/IPv6_Fragmentation_Concept-ar.svg/300px-IPv6_Fragmentation_Concept-ar.svg.png)
تقطيع رزمة البيانات وإعادة تجميعها هو وظيفة من وظائف الإصدار السادس من بروتوكول الإنترنت. تحصل عملية التقطيع في المضيف المصدر عندما يكون طول الرزمة أكبر من وحدة النقل العظمى للمسار كاملًا، وفيه تُقطَّع حمولة رزمة البيانات الأصلية إلى عدد من القطع ويُضاف لكل منها ترويسة البروتوكول وترويسة القطعة، وتُرسَل القطع إلى وجهة الرزمة الأصلية حيث يُصار إلى تجميعها. من أجل كل عملية تقطيع، يُولِّد المُضيف المصدر قيمة مُميزة تستعمل مُعرِّفًا، وتوضع في حقل المُعرِّف في ترويسة القطعة، وبهذا يمكن للمضيف الوجهة التعرُّف على القطع التي نتجت عن عملية تقطيع واحدة، في الحالات التي يستقبل فيها قطعًا ناتجة عن أكثر من عملية تقطيع من المصدر نفسه.[122]
نظريًّا، يمكن إرسال رزمة بيانات تبلغ من الطول 65535 بايتًا من غير تقطيعها ولكن غالبًا ما يلزم التقطيع للتماشي مع طول نقل أعظم أقل من هذه القيمة مُحدد سلفًا في طبقة الوصلة، أما طول رزمة البيانات الأدنى الذي يدعمه البروتوكول فهو 1280 بايت.[35] يدعم البروتوكول أيضًا الرزم العملاقة (بالإنجليزية: Jumbogram)، وهي رزم بيانات يتراوح طولها بين 216=65535 و232=4294967295 بايت وتستخدم في شبكات بيانات تدعم أحجام نقل عظمى أكبر من 65535.[123]
التقطيع
[عدل]![](http://upload.wikimedia.org/wikipedia/commons/thumb/5/57/IPv6_Fragmentation_algorithm-ar.svg/300px-IPv6_Fragmentation_algorithm-ar.svg.png)
يعامِل المُضيف المصدر رزمة البيانات التي يريد تقطيعها على أنها مكوِّنة من ثلاثة أجزاء:[124]
- الترويسات التي ستوضع في القطع كلها: تضم هذه الترويسات ترويسة الإصدار السادس وترويسات التوسعة التالية لها حتى ترويسة التوجيه، إن وجدت، وإلا فحتى ترويسة خيارات المسار، إن وجدت، فإن غابت الترويستان السابقتان ضمَّ هذا الجزء ترويسة الإصدار السادس فقط.
- ترويسات التوسعة والطبقات العليا: وتضم جميع ترويسات التوسعة الأخرى التي لم تُشمل في القسم السابق، أما ترويسات الطبقات العليا فتشمل جميع الترويسات التي ليست ترويسات توسعة مثل ترويسات بروتوكول التحكم بالنقل وبروتوكول حزم بيانات المستخدم أو ترويسة بروتوكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت.(12)
- الحمولة: وهي القسم الذي سوف يُقطَّع، ويبدأ بعد ترويسات الطبقات العليا.
تجري عملية التقطيع وفق الخطوات التالية:[5]
- تحديد طول رزمة الإصدار السادس التي ستنتج عن التقطيع.
- إنشاء القطعة الأولى، وهي تتضمن ما يأتي وفقًا لتسلسل الورود: الترويسات التي ستوضع في القطع كلها وترويسة القطعة وترويسات التوسعة والطبقات العليا وقطعة من الحمولة، يحدد طولها كما يأتي:
- يُحسب مجموع أطوال الترويسات التي ستوضع في القطع كلها وترويسة القطعة وترويسات التوسعة والطبقات العليا.
- يُطرح المجموع من طول رزمة الإصدار السادس المُحدد بالخطوة الأولى، والناتج هو طول حمولة القطعة الأولى.
- تُقتطع حمولة القطعة الأولى من حمولة الرزمة الأصلية.
- تحديد عدد القطع اللازم تقطيعها بتقسيم حمولة الرزمة الأصلية، بعد اقتطاع حمولة القطعة الأولى، على طول الرزمة المُحدد بالخطوة الأولى، إذا كان الجواب كسريًّا، فإن القسم الصحيح هو عدد القطع الوسطى، أي التي تقع بين القطعتين الأولى والأخيرة، وأما الجزء الكسري، فيمثل القطعة الأخيرة.
- تقسم حمولة الرزمة الأصلية، بعد اقتطاع حمولة القطعة الأولى، إلى عدد القطع المحددة بالخطوة الرابعة.
- إنشاء القطع الوسطى: تتضمن القطع الوسطى الترويسات التي ستوضع في القطع كلها وترويسة القطعة وقطعة من الحمولة الناتجة عن الخطوة الخامسة ما خلا القطعة الأخيرة إذا كان عدد القطع كسريًّا.
- إنشاء القطعة الأخيرة: وتتضمَّن الترويسات التي ستوضع في القطع كلها وترويسة القطعة والقطعة الأخيرة من الحمولة الناتجة عن الخطوة الخامسة.
إعادة التجميع
[عدل]![](http://upload.wikimedia.org/wikipedia/commons/thumb/3/38/Reassemled_packet-ar.svg/300px-Reassemled_packet-ar.svg.png)
تحصل عملية إعادة التجميع في المضيف الوجهة فقط، وفيه تُستخلص حمولة القطع المُستقبلة ويُعاد ترتيبها وفقا لموقعها الأصلي المُحدد بحقل إزاحة القطعة، ويُصار إلى تشكيل رزمة البيانات الأصلية كما كانت قبل التقطيع في المضيف المصدر. يُشترط أن يكون عنوان المصدر وعنوان الوجهة وقيمة الحقل المُعرِّف متطابقة في جميع القطع التي سيعاد تجميعها. لإعادة تجميع الرزمة الأصلية، يبدأ المضيف الوجهة بإنشاء ترويسة الإصدار السادس من بروتوكول الإنترنت، ثُمَّ يستخلص أيضًا نسخة من الترويسات الموجودة في كل قطعة، ويضيفها بعد ترويسة البروتوكول، ويضيف بعدها أيضًا ترويسات التوسعة وترويسات الطبقات العليا إن وجدت، مع الانتباه لقيمة حقل الترويسة التالية في كل منها للحفاظ على تتابع الترويسات بشكلٍ سليم. بعد ذلك يحدد المضيف الوجهة الموقع النسبي لكل قطعة من الحمولة في رزمة البيانات الأصلية مُشكلًا حمولة الرزمة الأصلية، ثم يَحسب طول هذه الحمولة ويضيفه إلى ترويسة الإصدار السادس، وأخيرًا تُغلَّف الحمولة وترويسات الطبقات العليا والتوسعة وترويسة الإصدار السادس من بروتوكول الإنترنت داخل رزمة بيانات جديدة تتطابق مع رزمة البيانات الأصيلة قبل التقطيع.[125]
إدارة حركة البيانات
[عدل]تعريف تدفقات حركة البيانات
[عدل]يُستعمل حقل لافتة التدفق في ترويسة الإصدار السادس من بروتوكول الإنترنت لتعريف تدفق من رزم البيانات. وفقًا لمعيار البروتوكول، فإن رزم البيانات تنتمي لتدفق محدد إذا تطابقت ثلاثُ قيم فيها: عنوان مصدرها، وعنوان وجهتها وقيمة حقل لافتة التدفق فيها. تصنَّف رزم البيانات في الشبكة وفقًا للتدفق الذي تنتمي إليه، ثُمَّ تعامل على هذا الأساس، ويختص البروتوكول بتعريف آلية لتمييز تدفق الرزم، أما نوعية الخدمات المُقدَّمة للتدفقات فهي خارج نطاق محدداته.[126]
يبلغ طول حقل اللافتة 20 بتًّا، ويلزم أن يختار المضيف المصدر قيمته بشكل عشوائي وفريد بحيث لا يُولِّد مُعرفين متطابقي القيمة لأجل تدفقين مختلفين في الوقت نفسه. إذا كانت قيمة حقل اللافتة صفرية، فهذا يعني أن رزمة البيانات لا تنتمي لأي تدفق. بخلاف ذلك، فإن أي قيمة عددية يمكن تمثيلها باستعمال 20 بتًّا تصلح للاستخدام كمُعرِّف للتدفق.[127]
تصنيف حركة البيانات
[عدل]![](http://upload.wikimedia.org/wikipedia/commons/thumb/1/17/IPv6_Traffic_Class_Field_Structure-ar.svg/300px-IPv6_Traffic_Class_Field_Structure-ar.svg.png)
وهي آلية للتمييز بين رزم بيانات الإصدار السادس من بروتوكول الإنترنت اعتمادًا على قيم حقل صنف حركة البيانات ذي البتات الثمانية في ترويسة البروتوكول، تُضبط هذه القيم هي العقدة المصدر أو في العقد التي تعالج الرزمة على طول المسار. بعد ذلك، تُمنح الخدمات وأولوية المعالجة للرزم بناء على قيمة هذا الحقل.[128] طُبقت آلية مشابهة في الإصدار الرابع من بروتوكول الإنترنت، وسُمي الحقل المختص بها في ترويسة البروتوكول بحقل توع الخدمة، وكان طوله 8 بت أيضًا.[129]
يُقسَّم حقل صنف حركة البيانات إلى قسمين، هما قسم موقع ترميز الخدمات المتمايزة (بالإنجليزية: Differentiated services codepoint) ويشغل البتات الستة الأكثر أهمية من الحقل، وقسم البتات غير المُستعملة ويشمل البتين الأخيرين.[130] وتحدد الوثيقة RFC 2474 بنية محددة لقسم موقع الترميز هي: "xxx000" حيث تُمثِّل x بتًّا واحدًا قد تكون قيمته 0 أو 1، ويسمح ذلك بإنشاء 8 أصناف متمايزة لرزم البيانات.[131] يُحجز الترميز "000000" ليكون القيمة الافتراضية الدائمة لهذا الحقل، أما القيم السبعة الأخرى، أي {"001000"، "010000"، "011000"... "111000"}، فهي قابلة للتهيئة وفقًا للحاجة ولتعريف مستويات جودة الخدمة المطلوبة.[132]
المُشكلات
[عدل]مرتبطة بتقطيع البيانات
[عدل]ينتج عن استخدام التقطيع في الإصدار السادس من بروتوكول الإنترنت عدد من الثغرات الأمنيّة التي قد تستخدم لشن هجمات مثل هجوم القطعة الصغيرة أو هجوم القطع المتراكبة، وتختلف إمكانية شن الهجمات وفقًا لنظام التشغيل الذي يستعمل البروتوكول.[ar 2] بشكلٍ مُشابه للإصدار الرابع من بروتوكول الإنترنت، لم تمنع مُحددات الإصدار السادس إنشاء قطع متراكبة عند التقطيع، أي من الممكن أن يتكرر المقطع نفسه من الحمولة في أكثر من قطعة، على أن يُعتمد المقطع الوارد في آخر قطعة تمّ استقبالها عند التجميع، يسبب ذلك ثغرة أمنية، ويسمح بتنفيذ هجوم القطع المتراكبة، لاحقًا أُكِّد بوضوح على منع تراكب القطع عند التقطيع في وثيقة طلب التعليقات RFC 5722.[133]
يقبل مُضيف الإصدار السادس من بروتوكول الإنترنت أن تحتوي رزمة البيانات على ترويسة القطعة من غير أن تكون القطعة ناتجة عن عملية تقطيع، وتسمى هذه القطع بالقطع الذرية (بالإنجليزية: Atomic Fragment) وهي تنتج في حالات خاصة ناقشها المعيار الأصلي للبروتوكول،[134] على الرغم من أن هذه القطع تكون وحدانًا، أي لا يجب تجميعها مع أي قطع أخرى، فإنّ المُضيف الوجهة يعاملها مُعاملة القطع التي تنتظر التجميع، ما يُسبب ثغرة أمنية، فقد يرسل المهاجم قطعة خبيثة مع قيم مُناسبة في ترويسة القطعة، بحيث تكون قطعة ذرية تقبل التجميع مع قطع أخرى خبيثة تُرسل لاحقًا، ناقشت الوثيقة RFC 6946 كيفية معالجة القطع الذرية لتلافي هذا النوع من الهجمات.[135]
مرتبطة بإدارة حركة البيانات
[عدل]يُمكن تزوير قيمة حقل لافتة التدفق في رزمة بيانات ما من أجل حصولها على خدمة محددة أو معاملة تفضيلية عند معالجتها،[136] ولا توجد طريقة لحماية حقل التدفق في ترويسة البروتوكول من العبث حتى ولو استعملت حزمة بروتوكول الإنترنت الأمنية،[137] ويُشكِّل هذا ثغرة أمنية، ويُستحسن أن تكون قيمة هذا الحقل شبه عشوائية بحيث يصعب على المهاجم تخمين قيمة المعرف المُستعمل.[ar 2] يُمكن أيضًا أن تُستخدم قيمة حقل لافتة التدفق من أجل إجراء تحليل لحركة البيانات في الشبكة، أو لتتبع حركة بيانات مُحددة. وحتى لو عُمِّيت الرسالة، فإن تعمية قيمة ثابتة غير متغيرة قد ينتج قيمًا ثابتة في الرسالة المعماة تساعد في تحليلها أو في كشف آلية التعمية أو في كشف ترتيب البيانات في الرسالة.[138]
يوجد هجوم يُسمى هجوم سرقة الخدمة (بالإنجليزية: Theft of Service) وفيه تُغيَّر قيمة حقل صنف الخدمة في رزمة بيانات ما من أجل زيادة أولويتها أو رفع جودة الخدمة المُقدمة لها، كما يُمكن أن يُشنَّ هجوم حجب الخدمة أيضًا من خلال تغيير قيمة حقل صنف الخدمة، لجعل رزمة أو مجموعة رزم بيانات تحصل على جودة خدمة أقل من الجودة المتوقعة لها، وقد يسبب هذا تأخيرًا زمنيًّا في وصولها إلى هدفها أو التخلص منها في الوجهة.[8]
بروتوكولات رديفة
[عدل]بروتوكول رسائل التحكم في الإنترنت للإصدار السادس
[عدل]بروتوكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت | |
---|---|
اختصار | ICMPv6 |
الوظيفة | بروتوكول مساعد للإصدار السادس من بروتوكول الإنترنت |
المُطوِّر | مجموعة مهندسي الإنترنت |
تاريخ التطوير | ديسمبر 1995 |
مبني على | بروتوكول رسائل التحكم في الإنترنت |
طبقة نموذج OSI | طبقة الشبكة |
وثيقة طلب التعليقات RFC | RFC 4443[29] |
تعديل مصدري - تعديل ![]() |
بروتوكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت (بالإنجليزية: Internet Control Message Protocol for IPv6 اختصارًا ICMPv6) هو بروتوكول مساعد للإصدار السادس من بروتوكول الإنترنت وجزءٌ مدمج منه، طُوِّر هذا البروتوكول بالتوازي مع الإصدار السادس من بروتوكول الإنترنت وصدر معياره الأصلي في شهر ديسمبر من العام 1995م ووصف في وثيقة طلب التعليقات RFC 1885.[23]
تستعمل العقد التي تُشغِّل الإصدار السادس من بروتوكول الإنترنت بروتوكول رسائل التحكم للتبليغ عن الأخطاء الحاصلة في أثناء معالجة رزم البيانات ولأداء وظائف أخرى مرتبطة بطبقة الشبكة مثل تشخيص المُشكلات باستعمال أمر التحقق من المسار، ويلزم أن يكون مدعومًا بشكل كامل في العقد التي تشغل الإصدار السادس من بروتوكول الإنترنت جميعِها.[139]
يُعرِّف البروتوكول ترويسة خاصة به طولها 4 بايت، تُضاف بعد ترويسة الإصدار السادس. ولهذه الترويسة مُعرِّف مميز هو 58، يلزم أن يُشار إليه في حقل الترويسة التالية في داخل الترويسة التي تسبق ترويسة هذا البروتوكول. بالإضافة لذلك، يُعرِّف المعيار الأصلي للبروتوكول 4 رسائل أخطاء وثلاث رسائل استعلام.[140] ولكن أضيفت العديد من الرسائل لاحقًا لخدمة وظائف مختلفة مثل رسائل التماس الموجه التي أضافها بروتوكول اكتشاف الجيران وغير ذلك.[Web 13]
في شهر ديسمبر من العام 1998 صدر تحديث جديد للبروتوكول في وثيقة طلب التعليقات RFC 2463،[27] وبعدها بثمانية سنوات صدرت الوثيقة RFC 4443 وهي المعيار الحالي للبروتوكول وهي تتضمن تفصيلًا إضافيًّا عن الثغرات الأمنية التي يمكن استعماها لشن هجمات عبر البروتوكول وكيفية الوقاية منها ومجموعة من الاعتبارات اللازمة لهيئة أرقام الإنترنت المُخصصة من أجل تعريف أنواع رسائل جديدة.[29]
بروتوكول اكتشاف الجيران
[عدل]بروتوكول اكتشاف الجيران | |
---|---|
اختصار | NDP |
الوظيفة | بروتوكول مساعد للإصدار السادس من بروتوكول الإنترنت |
المُطوِّر | مجموعة مهندسي الإنترنت |
تاريخ التطوير | أغسطس 1996 |
مبني على | بروتوكول رسائل التحكم في الإنترنت |
طبقة نموذج OSI | طبقة الشبكة وطبقة الوصلة |
وثيقة طلب التعليقات RFC | RFC 4861 |
تعديل مصدري - تعديل ![]() |
بروتوكول اكتشاف الجيران (بالإنجليزية: Neighbor Discovery Protocol) هو بروتوكول مساعد للإصدار السادس من بروتوكول الإنترنت، يعمل بين الطبقتين الثانية والثالثة وفقًا نموذج الربط البيني للأنظمة المفتوحة، ويقدم خدمات التعرف على الموجهات والتعرف على الجيران وإعادة التوجيه. طرح المعيار الأصلي للبروتوكول في أغسطس من العام 1996 ووصف في وثيقة طلب التعليقات RFC 1970.[30]
يُعرِّف هذا البروتوكول 5 رسائل من بروتوكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت هن: رسالة إعادة التوجيه وزوجين من الرسائل لاكتشاف عناوين الموجهات في الشبكة المحلية، هما رسالة التماس الموجه ورسالة الإعلان عن الموجه، وزوجين لاكتشاف عناوين الجيران، هما رسالة التماس الجار ورسالة الإعلان عن الجار اللتان أدى بهما البروتوكول مع الإصدار السادس وظيفة اقتران العناوين بين الطبقتين الثالثة والثانية، وهي الوظيفة نفسها التي يؤديها بروتوكول اقتران العناوين مع الإصدار الرابع من بروتوكول الإنترنت.[141]
طُوِّرت أشكال متنوعة مشتقة من هذا البروتوكول، منها بروتوكول اكتشاف الجيران العكسيّ (بالإنجليزية: Inverse Neighbor Discovery Protocol) الذي يؤدي وظيفة اقتران العناوين العكسية بين الطبقتين الثانية والثالثة والذي وصف في الوثيقة RFC 3122 على أنه توسعة لبروتوكول اكتشاف الجيران،[142] وأيضًا بروتوكول اكتشاف الجيران الآمن (بالإنجليزية: SEcure Neighbor Discovery Protocol اختصارًا SEND) الذي يُعرِّف آلياتٍ آمنة لتبادل بيانات الشبكة وفق بروتوكول اكتشاف الجيران، وقد وُصِف في وثيقة طلب التعليقات RFC 3971.[143]
صدر تحديث جديد للمعيار في ديسمبر من العام 1998م، وحملت الوثيقة الاسم الرمزي RFC 2461. ثم صدرت الوثيقة RFC 4861 في شهر سبتمبر من العام 2007م، وهي المعيار الحالي لبروتوكول اكتشاف الجيران.[30]
بروتوكول اكتشاف مستمعي البث المجموعاتي
[عدل]بروتوكول اكتشاف مستمعي البث المجموعاتي | |
---|---|
الوظيفة | إدارة مجموعة البث المجموعاتي في الإصدار السادس من بروتوكول الإنترنت |
المُطوِّر | مجموعة مهندسي الإنترنت |
تاريخ التطوير | 2004 |
طبقة نموذج OSI | طبقة الشبكة |
وثيقة طلب التعليقات RFC | RFC 3810[144] |
تعديل مصدري - تعديل ![]() |
بروتوكول اكتشاف مستمعي البث المجموعاتي (بالإنجليزية: Multicast Listener Discovery اختصاراً MLD) هو بروتوكول اتصال يعمل على مستوى الطبقة الثالثة وفقًا لنموذج الربط البيني للأنظمة المفتوحة، يدير المجموعات الخاصة بالبث المجموعاتي لرزم الإصدار السادس من بروتوكول الإنترنت، وبشكلٍ خاص اكتشاف أعضاء المجموعات في الشبكات المحلية وتحديد أي المجموعات التي يهتمون باستقبال رزمها.[145]
يُقدّم البروتوكول مفهومًا خاصًّا بالإصدار السادس هو مفهوم مُستمع البث المجموعاتي (بالإنجليزية: Multicast Listener)، وهو وفقًا للتعريف، عقدة ترغب في استقبال رزم البث المجموعاتي. إذا استضاف المستمع عنوان مجموعة ما، أصبح عضوًا فيها، وبات يهتم باستقبال رزمها. يمكن أن ينضم المستمع إلى أكثر من مجموعة في الوقت نفسه. ومن هنا حصل البروتوكول على اسمه، فالبروتوكول يساعد تجهيزات الطبقة الثالثة المُتصلة مع الشبكة المحليّة على اكتشاف وجود المُستمعين فيها. يُوصف البروتوكول أيضًا بأنه غير متناظر (بالإنجليزية: Asymmertic)، لأنه يسلك سلوكًا مختلفًا عند تعامله مع المستمعين عن ذلك الذي يتبعه مع تجهيزات الطبقة الثالثة، مثل المُوجِّهات.[146]
يوجد إصداران لبروتوكول اكتشاف مستمعي الإنترنت، الإصدار الأول منه موصوف في وثيقة طلب التعليقات RFC 2710 [147] وقد طُوّر في العام 1999م، وهو مُكافئ للإصدار الثاني من بروتوكول إدارة مجموعة الإنترنت (IGMPv2) من حيث الوظيفة، أمّا الإصدار الثاني فطوّر في العام 2004م، وهو موصوف بالوثيقة RFC 3810[144] ويُكافئ الإصدار الثالث من بروتوكول إدارة مجموعة الإنترنت (IGMPv3)، ويدعم ميزات إضافية مثل البث المجموعاتي مُحدد المصدر [الإنجليزية].[148]
هوامش
[عدل]1. لا يُلزم المعيار منفذي البروتوكول اتباعَ الترتيب التالي اتباعًا إلزاميًّا، ولكنه يستحسن ذلك.[43]
2. في ما يخص محتويات ترويسة خيارات الوجهة، سواء كانت الوجهة الأولى أو وجهات البينية على مسار الرزمة، فهي تخضع لهذه القاعدة أيضًا. فإذا أُرسلت الرزمة عبر مسار محدد نحو وجهتها النهائية، فإن عناوين الوجهات البينية المتوقعة على طول المسار تكون موجودة في ترويسة التوجيه فيها، وتكون قيمة حقل عنوان الوجهة في ترويسة البروتوكول هي عنوان الوجهة الأولى. وعندما تصل الرزمة إلى الوجهة الأولى، فإن البروتوكول يُغيِّر قيمة عنوان الوجهة، ويضع بدلًا منه العنوان التالي الموجود في ترويسة التوجيه. عمليًّا، لم تُعالج ترويسات التوسعة في الرزمة حتى بلغت الرزمة وجهتها، وهذه الوجهة مُحددة بعنوان الوجهة في ترويسة البروتوكول.
3. في النوع ذو القيمة 0، يستطيع المضيف المصدر أن يحدد عناوين العقد التي ستمر فيها الرزمة بالترتيب، وسبب هذا إشكالًا أمنيًّا لأنه يسمح بإدراج العنوان نفسه أكثر من مرة في الترويسة نفسها، ويسبب هذا إعادة توجيه الرزمة نحو نفس العقدة أكثر من مرة خلال مسارها.[49]
4. القطاع الشبكي هو اتصال كهربائي مشترك بين منافذ الشبكة.[149]
5. يختلف تفسير معنى كلمة «أقرب» باختلاف بروتوكول التوجيه المُستعمل، فلكل بروتوكول توجيه آلية محددة لقياس وزن المسار، قد تعتمد على عدد القفزات للوجهة، أو على مُعدل النقل في الوصلات أو غير ذلك، ويتحدد المنفذ الأقرب حسبَ هذه الآلية.
6. يلزم أن تُكتب الحروف اللاتينية بالحالة الصغيرة لا الكبيرة، أي a لا A.[150]
7. لا تستخدم محددات البروتوكول كلمة رباعية، ولكن هذه الكلمة شائعة لوصف هذا المفهوم.
8. بسبب كون قيمة بت المحلية ثابتة دائماً على القيمة 1، لعدم وجود استخدام آخر لها حتى الآن، فإن بعض المراجع تشير لبادئة هذا الفضاء بالشكل fd::/8 بدلاً من fc::/7، وهذا خطأ شائع لا يجوز، لأن المعيار الرسمي يُشير إلى إمكانية تطوير لاحقة لاستخدامات أخرى لهذا العنوان تكون قيمة بت محلية فيها مساويةً للصفر.[110]
9. حُرر هذا الفضاء في شهر مارس من العام 2014، ولم يعد محجوزًا.[Web 6]
10. للتحصيص (بالإنجليزية: Allocation) وللتخصيص (بالإنجليزية: Assignment) معنيان متمايزان في نظام سجلات عناوين الأنترنت. يُشير الأول، أي التحصيص، إلى تفويض منظمةٍ بالإشراف على فضاءٍ جزئيٍّ من فضاء بروتوكول الإنترنت مع توقعٍ بقيام هذه المنظمة بتجزئة الفضاء وتفويض الأفضية الجزئية الناتجة إلى منظمات أخرى. أمّا الثاني، أي التخصيص، فهو يستعمل عند منح الفضاء إلى الجهات التي تستخدمه مباشرة في عنونة مجموعة من المضيفين.[151]
11. يُستثنى البت رقم (0) من المرتبة الستة عشرية الأولى، ولذلك فحدود نهاية معرّف الشبكة الجزئية الخاصة بها تضمّ البتات ذات الفهارس {1,2} فقط، والسبب في ذلك أن استعماله يعني بادئة شبكة بطول (0) بت، وهي حالة مستحيلة.
12. في هذا السياق، تُستثنى ترويسة تأمين الحمولة بالتغليف وتعامل معاملة ترويسة الطبقات العليا مع أنها من أنها ترويسة توسعة للإصدار السادس من البروتوكول.[124]
انظر أيضًا
[عدل]![]() |
في كومنز صور وملفات عن: بروتوكول الإنترنت |
المراجع
[عدل]فهرس المراجع
[عدل]- فهرس المنشورات العربية
- ^ بكني (2022)، ص. 204.
- ^ ا ب ج بكني، ص. 233.
- ^ بكني (2022)، ص. 211.
- فهرس المنشورات الأجنبية
- ^ ا ب RFC 1883, p. 1.
- ^ RFC 8200, p. 7-10.
- ^ ا ب Odom (2013), p. 579.
- ^ ا ب ج د RFC 4291, p. 2-3.
- ^ ا ب RFC 8200, p. 17-19.
- ^ ا ب RFC 6437, p. 7-10.
- ^ ا ب RFC 2474, p. 1-2.
- ^ ا ب RFC 2474, p. 15.
- ^ RFC 791, p. 1.
- ^ Odom (2013), p. 611.
- ^ RFC 791, p. 7.
- ^ Odom (2013), p. 296.
- ^ RFC 1112, p. 3.
- ^ ا ب RFC 4632, p. 4.
- ^ RFC 1338, p. 1.
- ^ RFC 1519, p. 1.
- ^ RFC 1631, p. 1.
- ^ Odom (2013), p. 612.
- ^ RFC 1550, p. 1.
- ^ RFC 1752, p. 2.
- ^ RFC 1752, p. 45.
- ^ RFC 1884, p. 1.
- ^ ا ب RFC 1885, p. 1.
- ^ RFC 1970, p. 1.
- ^ RFC 1971, p. 1.
- ^ [a] RFC 2460, p. 1.
[b] RFC 2461, p. 1.
[c] RFC 2462, p. 1.
- ^ ا ب RFC 2463, p. 1.
- ^ RFC 4291, p. 1.
- ^ ا ب ج RFC 4443, P.1
- ^ ا ب ج RFC 4861, p. 1.
- ^ RFC 4862, p. 1.
- ^ RFC 8200, p. 1.
- ^ Javvin (2005), p. 67.
- ^ RFC 8200, p. 4.
- ^ ا ب Fall (2012), p. 184.
- ^ RFC 8201, p. 1.
- ^ RFC 6437, p. 3.
- ^ ا ب RFC 8200, p. 5.
- ^ ا ب RFC 8200, p. 7.
- ^ ا ب ج RFC 8200, p. 9.
- ^ Fall (2012), p. 194.
- ^ RFC 8200, p. 24.
- ^ ا ب RFC 8200, p. 10.
- ^ RFC 8200, p. 8.
- ^ RFC 6275, p. 49.
- ^ RFC 7401, p. 38.
- ^ RFC 8200, p. 6-7.
- ^ ا ب RFC 8200, p. 13.
- ^ ا ب Fall (2012), p. 200.
- ^ RFC 791, p. 16.
- ^ ا ب RFC 8200, p. 14.
- ^ RFC 5095, p. 3.
- ^ RFC 8200, p. 15.
- ^ RFC 8200, p. 19.
- ^ RFC 8200, p. 15-16.
- ^ RFC 7739, p. 1.
- ^ ا ب 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.
- ^ Fall (2012), p. 196.
- ^ ا ب RFC 8200, p. 11.
- ^ RFC 8200, p. 12.
- ^ RFC 8200, p. 36-38.
- ^ RFC 8200, p. 12-13.
- ^ ا ب ج Odom (2013), p. 617.
- ^ ا ب RFC 4291, p. 7.
- ^ RFC 5952, p. 2.
- ^ Odom (2013), p. 619.
- ^ Odom (2013), 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.
- ^ Odom (2013), p. 634.
- ^ ا ب ج د ه RFC 4291, p. 11.
- ^ ا ب Odom (2013), p. 632.
- ^ RFC 4293, p. 2.
- ^ RFC 4293, p. 3-4.
- ^ RFC 3879, p. 1.
- ^ RFC 4038, p. 1.
- ^ ا ب RFC 4291, p. 12.
- ^ ا ب ج RFC 4291, p. 13.
- ^ Dyson (1999), p. 242.
- ^ RFC 3956, p. 5.
- ^ RFC 3306, p. 3.
- ^ RFC 7346, p. 3.
- ^ RFC 4291, p. 14.
- ^ RFC 3306, p. 1.
- ^ RFC 7371, p. 1.
- ^ RFC 6890, p. 14-20.
- ^ RFC 6052, p. 5.
- ^ RFC 6666, p. 4.
- ^ RFC 2928, p. 1.
- ^ RFC 4380, p. 4.
- ^ RFC 7723, p. 5.
- ^ RFC 8155, p. 9.
- ^ RFC 5180, p. 11.
- ^ RFC 7450, p. 78.
- ^ RFC 7535, p. 7.
- ^ RFC 4843, p. 5.
- ^ RFC 7343, p. 6.
- ^ RFC 3849, p. 1.
- ^ RFC 3056, p. 5.
- ^ ا ب RFC 4293, p. 3.
- ^ 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 (2017), p. 9-10.
- ^ RFC 7217, p. 5.
- ^ RFC 7020, p. 4-5.
- ^ Odom (2013), p. 639.
- ^ Kozierok (2005), p. 464.
- ^ RFC 8200, p. 15. -22
- ^ RFC 2675, p. 1.
- ^ ا ب 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.
- ^ RFC 5722, p. 1.
- ^ RFC 8200, p. 31.
- ^ RFC 6946, p. 1.
- ^ RFC 6437, p. 9.
- ^ RFC 6437, p. 10.
- ^ RFC 6437, p. 8.
- ^ RFC 4443, p. 3.
- ^ RFC 1885, p. 2.
- ^ RFC 4861, p. 11.
- ^ RFC 3122, p. 1.
- ^ RFC 3971, p. 1.
- ^ ا ب RFC 3810, p. 1.
- ^ Fall (2012), p. 451-453.
- ^ Rosen (2014), p. 230.
- ^ RFC 2710, p. 1.
- ^ RFC 4604, p. 1.
- ^ IEEE 802.3, p. 35.
- ^ RFC 5952, p. 10.
- ^ RFC 2050, p. 4.
- فهرس مواقع الويب
- ^ "Free Pool of IPv4 Address Space Depleted". Number Resource Organization (بالإنجليزية). 3 Feb 2011. Archived from the original on 2020-03-05. Retrieved 2019-03-06.
- ^ "Internet Protocol Version 6 (IPv6) Parameters - Next Header Types" (بالإنجليزية). Archived from the original on 2020-02-28. Retrieved 2020-05-23.
- ^ "Assigned Internet Protocol Numberss" (بالإنجليزية). Archived from the original on 2020-02-13. Retrieved 2020-05-23.
- ^ "Internet Protocol Version 6 (IPv6) Parameters" (بالإنجليزية). Archived from the original on 2020-05-07. Retrieved 2020-05-23.
- ^ "Protocol Numbers". IANA (بالإنجليزية). Archived from the original on 2018-01-04. Retrieved 2018-07-18.
- ^ ا ب "IANA IPv6 Special-Purpose Address Registry". IANA (بالإنجليزية). Archived from the original on 2020-01-02. Retrieved 2020-05-25.
- ^ ا ب ج "IPv6 Multicast Address Space Registry". IANA (بالإنجليزية). Archived from the original on 2020-05-07. Retrieved 2020-05-25.
- ^ "Internet Assigned Numbers Authority (IANA) Policy For Allocation of IPv6 Blocks to Regional Internet Registries (Ratified 7 September 2006)". icann.org (بالإنجليزية). Archived from the original on 2020-02-28. Retrieved 2020-03-08.
- ^ "IPv6 Global Unicast Address Assignments". IANA (بالإنجليزية). Archived from the original on 2020-02-16. Retrieved 2020-03-08.
- ^ "Understanding IP Addressing and CIDR Charts". RIPE NCC (بالإنجليزية). Archived from the original on 2020-02-15. Retrieved 2020-03-08.
- ^ "IPv6 Global Unicast Address Assignments". IANA (بالإنجليزية). Archived from the original on 2018-02-22. Retrieved 2018-09-02.
- ^ "Understanding IP Addressing and CIDR Charts". RIPE (بالإنجليزية). 4 Jan 2011. Archived from the original on 2018-08-26. Retrieved 2018-09-23.
- ^ "Internet Control Message Protocol version 6 (ICMPv6) Parametersry". IANA (بالإنجليزية). Archived from the original on 2020-05-07. Retrieved 2020-05-28.
معلومات المراجع المُفصَّلة
[عدل]- الكتب (مرتبة تصاعديًّا حسب تاريخ النشر)
الإنجليزية:
- Peter John Dyson (1999). Dictionary of Networking (بالإنجليزية) (3rd ed.). San Francisco: Sybex. ISBN:0-7821-2461-5. OCLC:43596809. OL:8096220M. QID:Q115917529.
- Network Protocols Handbook (بالإنجليزية) (2nd ed.). California: Javvin Technologies Inc. 2005. ISBN:978-0-9740945-2-6. OCLC:61854497. OL:8581250M. QID:Q118316084.
- Charles Kozierok (2005). The TCP/IP Guide: a comprehensive, illustrated Internet protocols (PDF) (بالإنجليزية). San Francisco: No Starch Press. ISBN:978-1-59327-047-6. OCLC:1047847974. OL:8871404M. QID:Q115917346.
- Rami Rosen (2014). Linux Kernel Networking: implementation and theory (بالإنجليزية). New York City: Apress. ISBN:978-1-4302-6197-1. OCLC:869747983. OL:37413258M. QID:Q119841470.
- Kevin R. Fall; W. Richard Stevens (2012). TCP/IP illustrated: Volume 1, The protocols (PDF) (بالإنجليزية) (2nd ed.). Boston: Addison-Wesley. ISBN:978-0-321-33631-6. OCLC:774930889. OL:25162208M. QID:Q115922106.
- Wendell Odom (2013). Cisco CCENT/CCNA ICND1 100-101 Official Cert Guide (بالإنجليزية). Indianapolis: Cisco Press. ISBN:978-1-58714-485-1. OCLC:863128088. OL:26185412M. QID:Q115919723.
العربية:
- ميشيل بكني (2022). ساندرا هانبو (المحرر). بروتوكول الإِنترنت: الإِصداران الرابع والسادس. أورتيز: مطبعة إيسن. DOI:10.6084/M9.FIGSHARE.19326086. ISBN:978-2-9576887-1-5. OCLC:1425075897. OL:36773625W. QID:Q111284802.
- وثائق طلب التعليقات (مرتبة تصاعديًّا حسب رقم الوثيقة)
- J. Postel (1981-09), Internet Protocol: DARPA Internet Program, Protocol Specification (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC0791, RFC:791, QID:Q47467078
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - S.E. Deering (1989-08), Host extensions for IP multicasting (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1112, RFC:1112, QID:Q47460092
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - T. Li (1992-06), Supernetting: an Address Assignment and Aggregation Strategy (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1338, RFC:1338, QID:Q47468405
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - Y. Rekhter; T. Li (1993-09), An Architecture for IP Address Allocation with CIDR (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1518, RFC:1518, QID:Q47314090
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - T. Li (1993-09), Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1519, RFC:1519, QID:Q47199620
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - S. Bradner; A. Mankin (1993-12), IP: Next Generation (IPng) White Paper Solicitation (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1550, RFC:1550, QID:Q47470454
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - K. Egevang; P. Francis (1994-05), The IP Network Address Translator (NAT) (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1631, RFC:1631, QID:Q47164409
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - S. Bradner; A. Mankin (1995-01), The Recommendation for the IP Next Generation Protocol (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1752, RFC:1752, QID:Q47457995
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - S. Deering; R. Hinden (1995-12), Internet Protocol, Version 6 (IPv6) Specification (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1883, RFC:1883, QID:Q47472593
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - S. Deering; R. Hinden (1995-12), IP Version 6 Addressing Architecture (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1884, RFC:1884, QID:Q47461872
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - S. Deering (1995-12), Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1885, RFC:1885, QID:Q47468348
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - W. Simpson; T. Narten; E. Nordmark (1996-08), Neighbor Discovery for IP Version 6 (IPv6) (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1970, RFC:1970, QID:Q47474638
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - T. Narten (1996-08), IPv6 Stateless Address Autoconfiguration (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC1971, RFC:1971, QID:Q47471157
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - J. Postel (1996-11), Internet Registry IP Allocation Guidelines (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC2050, RFC:2050, QID:Q47483471
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - S. Deering; R. Hinden (1998-12), Internet Protocol, Version 6 (IPv6) Specification (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC2460, RFC:2460, QID:Q47467387
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - W. Simpson; T. Narten; E. Nordmark (1998-12), Neighbor Discovery for IP Version 6 (IPv6) (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC2461, RFC:2461, QID:Q47466167
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - T. Narten (1998-12), IPv6 Stateless Address Autoconfiguration (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC2462, RFC:2462, QID:Q47469328
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - S. Deering (1998-12), Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC2463, RFC:2463, QID:Q47455723
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - F. Baker; D. Black (1998-12), Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC2474, RFC:2474, QID:Q47470529
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - S. Deering; R. Hinden; D. Borman (1999-08), IPv6 Jumbograms (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC2675, RFC:2675, QID:Q47468506
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - S. Deering; B. Haberman; W. Fenner (1999-10), Multicast Listener Discovery (MLD) for IPv6 (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC2710, RFC:2710, QID:Q47464272
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - S. Deering; R. Hinden (2000-09), Initial IPv6 Sub-TLA ID Assignments (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC2928, RFC:2928, QID:Q47466415
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - A. Conta (2001-06), Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC3122, RFC:3122, QID:Q47477469
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - B. Carpenter (2001-02), Connection of IPv6 Domains via IPv4 Clouds (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC3056, RFC:3056, QID:Q47477513
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - D. Thaler; B. Haberman (2002-08), Unicast-Prefix-based IPv6 Multicast Addresses (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC3306, RFC:3306, QID:Q47472870
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - R. Vida; L. Costa (2004-06), Multicast Listener Discovery Version 2 (MLDv2) for IPv6 (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC3810, RFC:3810, QID:Q47467351
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - G. Huston (2004-07), IPv6 Address Prefix Reserved for Documentation (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC3849, RFC:3849, QID:Q47468196
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - C. Huitema; B. Carpenter (2004-09), Deprecating Site Local Addresses (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC3879, RFC:3879, QID:Q47322494
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - B. Haberman (2004-11), Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC3956, RFC:3956, QID:Q47476136
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - J. Arkko (2005-03), SEcure Neighbor Discovery (SEND) (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC3971, RFC:3971, QID:Q47312783
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - M-K. Shin; Y-G. Hong; J. Hagino; P. Savola; E. M. Castro (2005-03), Application Aspects of IPv6 Transition (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC4038, RFC:4038, QID:Q47481039
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - S. Deering; R. Hinden (2006-02), IP Version 6 Addressing Architecture (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC4291, RFC:4291, QID:Q47470884
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - R. Hinden; B. Haberman (2005-10), Unique Local IPv6 Unicast Addresses (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC4193, RFC:4193, QID:Q47470421
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - S. Kent (2005-12), IP Authentication Header (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC4302, RFC:4302, QID:Q47469832
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - S. Kent (2005-12), IP Encapsulating Security Payload (ESP) (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC4303, RFC:4303, QID:Q47468417
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - C. Huitema (2006-02), Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs) (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC4380, RFC:4380, QID:Q47455351
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - B. Haberman (2006-08), Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC4604, RFC:4604, QID:Q47461464
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - T. Li (2006-08), Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC4632, RFC:4632, QID:Q47485207
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - P. Nikander; J. Laganier; F. Dupont (2007-04), An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID) (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC4843, RFC:4843, QID:Q47468599
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - W. Simpson; T. Narten; E. Nordmark (2007-09), Neighbor Discovery for IP version 6 (IPv6) (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC4861, RFC:4861, QID:Q47465975
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - T. Narten (2007-09), IPv6 Stateless Address Autoconfiguration (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC4862, RFC:4862, QID:Q47483181
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - J. Abley; P. Savola; G. Neville-Neil (2007-12), Deprecation of Type 0 Routing Headers in IPv6 (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC5095, RFC:5095, QID:Q47322771
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - C. Popoviciu; A. Hamza; G. Van de Velde; D. Dugatkin (2008-05), IPv6 Benchmarking Methodology for Network Interconnect Devices (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC5180, RFC:5180, QID:Q47320263
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - S. Krishnan (2009-12), Handling of Overlapping IPv6 Fragments (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC5722, RFC:5722, QID:Q47483158
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - S. Kawamura; M. Kawashima (2010-08), A Recommendation for IPv6 Address Text Representation (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC5952, RFC:5952, QID:Q47462322
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - C. Perkins; J. Arkko (2011-07), Mobility Support in IPv6 (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC6275, RFC:6275, QID:Q47472726
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - B. Carpenter; S. Jiang (2011-11), IPv6 Flow Label Specification (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC6437, RFC:6437, QID:Q47461703
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - M. Boucadair; C. Huitema (2010-10), IPv6 Addressing of IPv4/IPv6 Translators (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC6052, RFC:6052, QID:Q47471511
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - D. Freedman; N. Hilliard (2012-08), A Discard Prefix for IPv6 (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC6666, RFC:6666, QID:Q47471990
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - R. Bonica; B. Haberman (2013-04), Special-Purpose IP Address Registries (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC6890, RFC:6890, QID:Q47462480
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - F. Gont (2013-05), Processing of IPv6 "Atomic" Fragments (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC6946, RFC:6946, QID:Q47484143
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - R. Housley; G. Huston (2013-08), The Internet Numbers Registry System (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC7020, RFC:7020, QID:Q47463802
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - F. Gont (2014-04), A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC7217, RFC:7217, QID:Q47470898
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - J. Laganier; F. Dupont (2014-09), An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC7343, RFC:7343, QID:Q47483506
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - R. Droms (2014-08), IPv6 Multicast Address Scopes (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC7346, RFC:7346, QID:Q47301999
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - M. Boucadair; S. Venaas (2014-09), Updates to the IPv6 Multicast Addressing Architecture (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC7371, RFC:7371, QID:Q47207470
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - R. Moskowitz; T. Heer; P. Jokela; T. Henderson (2015-04), Host Identity Protocol Version 2 (HIPv2) (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC7401, RFC:7401, QID:Q47455650
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - G. Bumgardner (2015-02), Automatic Multicast Tunneling (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC7450, RFC:7450, QID:Q47466972
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - W. Kumari (2015-05), AS112 Redirection Using DNAME (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC7535, RFC:7535, QID:Q47246249
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - S. Kiesel; R. Penno (2016-01), Port Control Protocol (PCP) Anycast Addresses (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC7723, RFC:7723, QID:Q47471706
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - F. Gont (2016-02), Security Implications of Predictable Fragment Identification Values (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC7739, RFC:7739, QID:Q47476057
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - T. Reddy; P. Patil; D. Wing (2017-04), Traversal Using Relays around NAT (TURN) Server Auto Discovery (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC8155, RFC:8155, QID:Q47201872
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - S. Deering; R. Hinden (2017-07), Internet Protocol, Version 6 (IPv6) Specification (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC8200, RFC:8200, QID:Q47476951
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help) - J. Mogul; S. Deering; R. Hinden (2017-07), Path MTU Discovery for IP version 6 (بالإنجليزية), Internet Engineering Task Force, DOI:10.17487/RFC8201, RFC:8201, QID:Q47456249
{{استشهاد}}
: تحقق من التاريخ في:|publication-date=
(help)
- معايير تقانة (مرتبة تصاعديًّا حسب تاريخ النشر)
- 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 (بالإنجليزية). Institute of Electrical and Electronics Engineers. 2008. DOI:10.1109/IEEESTD.2008.4726971. ISBN:978-0-7381-5796-2. OCLC:874809175. QID:Q117948716.
- Guidelines for Use of Extended Unique Identifier (EUI), Organizationally Unique Identifier (OUI), and Company ID (CID) (PDF) (بالإنجليزية), Institute of Electrical and Electronics Engineers, 2017, QID:Q118316116
وصلات خارجية
[عدل]- الإصدار السادس من بروتوكول الإنترنت للجميع كتيب من إعداد مجتمع الإنترنت.
- التقطيع في الإصدار السادس من بروتوكول الإنترنت، مقالة من جيف هوستِن.
- اكتشاف الجيران والتهيئة الذاتية الآلية في الإصدار السادس من بروتوكول الإنترنت، مقالة من توماس نارتِن.
- أمن الإصدار السادس من بروتوكول الإنترنت، أسئلة متكررة، مقالة من مجتمع الإنترنت.
- أمن الشبكات، أمن الإصدار السادس لمهندسي الإصدار الرابع، مقالة من مجتمع الإنترنت.