ما هو الدافع لإضافة علامة IPv6_v6only؟

Question

في شبكات IPv6 ، يتم استخدام علامة IPv6_v6only للتأكد من أن المقبس سيستخدم فقط IPv6 ، ولا سيما أن رسم خرائط IPv4 إلى IPv6 لن يتم استخدامه لهذا المقبس. في العديد من نظام التشغيل ، لا يتم تعيين IPv6_v6only بشكل افتراضي ، ولكن على بعض نظام التشغيل (على سبيل المثال Windows 7) ، يتم تعيينه افتراضيًا.

سؤالي هو: ما هو الدافع لتقديم هذا العلم؟ هل هناك شيء حول رسم خرائط IPv4 إلى IPV6 الذي كان يسبب مشاكل ، وبالتالي يحتاج الناس إلى طريقة لتعطيله؟ يبدو لي أنه إذا لم يرغب شخص ما في استخدام رسم خرائط IPv4 إلى IPv6 ، فلن يتمكن ببساطة من تحديد عنوان IPv6 الذي تم تعيينه IPv4. ماذا أفتقد هنا؟

Answer 1

لا أعرف لماذا سيكون افتراضيًا ؛ لكن هذا النوع من الأعلام التي سأضعها دائمًا صريحة ، بغض النظر عن الافتراضي.

حول سبب وجوده في المقام الأول ، أعتقد أنه يسمح لك بالحفاظ على خوادم IPv4 الحالية فقط ، وتشغيل خوادم جديدة فقط على نفس المنفذ ولكن فقط لاتصالات IPv6. أو ربما يمكن للخادم الجديد ببساطة أن يقوم العملاء بتكييف إلى الخادم القديم ، مما يجعل وظيفة IPv6 سهلة وغير مؤلمة لإضافتها إلى الخدمات القديمة.

Answer 2

لا تدعم جميع الأنظمة الأساسية لـ IPv6 القادرة مآخذ DualStack ، لذا يصبح السؤال كيف يمكن للتطبيقات التي تحتاج إلى زيادة توافق IPv6 إما معرفة DualStack أو يتم ربطها بشكل منفصل عندما لا يكون ذلك؟ الإجابة الشاملة الوحيدة هي IPv6_v6only.

قد يجد التطبيق الذي يتجاهل IPv6_v6only أو مكتوبًا قبل وجود مكدسات IP DualStack القادرة على ذلك بشكل منفصل إلى V4 ، في بيئة ثنائية الثنائي حيث أن مقبس IPv6 DualStack يرتبط بربط IPv4 الممنع. قد لا يتوقع التطبيق أيضًا IPv4 عبر IPv6 بسبب مخاوف معالجة البروتوكول أو مستوى التطبيق أو عناصر التحكم في الوصول إلى IP.

هذه المواقف أو على الأرجح دفعت MS et al إلى الافتراضي إلى 1 حتى RFC3493 تعلن أن 0 هو الافتراضي. 1 من الناحية النظرية يزيد من التوافق المتخلف. على وجه التحديد لا يدعم Windows XP/2003 مآخذ DualStack.

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

Answer 3

والسبب الذي يذكره في أغلب الأحيان هو الحالة التي يكون فيها الخادم لديه شكل من أشكال ACL (قائمة التحكم في الوصول). على سبيل المثال ، تخيل خادمًا له قواعد مثل:

Allow 192.0.2.4
Deny all

يعمل على IPv4. الآن ، يقوم شخص ما بتشغيله على جهاز يحتوي على IPv6 ، واعتمادًا على بعض المعلمات ، يتم قبول طلبات IPv4 على مقبس IPv6 ، تم تعيينها على أنها :: 192.0.2.4 ثم لم تعد مطابقة لـ ACL الأول. فجأة ، سيتم إنكار الوصول.

أن تكون صريحًا في التطبيق الخاص بك (باستخدام IPv6_v6only) سيحل المشكلة ، مهما كان الافتراضي الذي لدى نظام التشغيل.

Answer 4

بالنسبة إلى Linux ، عند كتابة خدمة تستمع إلى كل من مآخذ IPv4 و IPv6 على نفس منفذ الخدمة ، مثل المنفذ 2001 ، يجب عليك الاتصال SetSockOpt (S ، Sol_ipv6 ، ipv6_v6only ، & one ، sizeof (واحد)) ؛ على مقبس IPv6. إذا لم تقم بذلك ، فإن عملية BIND () لمقبس IPv4 تفشل مع "العنوان المستخدم بالفعل".

Answer 5

هناك طرق معقولة يمكن من خلالها استخدام عناوين "IPv4" التي تم تعليمها (IPv4 "للتحايل على الأنظمة التي تم تكوينها بشكل سيء ، أو حتى في نظام تم تكوينه جيدًا. قد يرغب المطور في استخدام هذه العلامة لجعل تطبيقه أكثر أمانًا من خلال عدم الاستفادة من هذا الجزء من واجهة برمجة التطبيقات.

نرى: http://ipv6samurais.com/ipv6samurais/openbsd-audit/draft-cmetz-v6ops-v4mped-api-harmful-01.txt

Answer 6

تخيل بروتوكول يتضمن عنوان شبكة في المحادثة ، على سبيل المثال قناة البيانات الخاصة بـ FTP. عند استخدام IPv6 ، سترسل عنوان IPv6 ، إذا كان المستلم هو عنوان معين IPv4 ، فلن يكون له أي طريقة للتواصل مع هذا العنوان.

Answer 7

هناك مثال واحد شائع جدًا حيث يمثل ازدواجية السلوك مشكلة. المعيار getaddrinfo() الاتصال مع AI_PASSIVE يوفر العلم إمكانية تمرير أ اسم العقدة المعلمة وإرجاع قائمة العناوين للاستماع إليها. يتم قبول قيمة خاصة في شكل سلسلة فارغة اسم العقدة ويشير إلى الاستماع على عناوين البدل.

على بعض الأنظمة 0.0.0.0 و :: يتم إرجاعها بهذا الترتيب. عندما يتم تمكين مأخذ التوصيل المزدوج بشكل افتراضي ولا تقوم بتعيين المقبس IPV6_V6ONLY, ، يتصل الخادم بـ 0.0.0.0 ثم يفشل في الاتصال بجائزة مزدوجة :: وبالتالي (1) يعمل فقط على IPv4 و (2) خطأ تقارير.

أود أن أعتبر الأمر خطأ حيث من المتوقع أن يفضل IPv6. ولكن حتى عندما تحاول أول مكدس مزدوج :: ثم IPv4 فقط 0.0.0.0, ، لا يزال الخادم يوضح خطأً للمكالمة الثانية.

أنا شخصياً أفكر في الفكرة الكاملة عن مقبس المكجمات المزدوجة. في مشروعي ، أفضل ضبطه بشكل صريح دائمًا IPV6_V6ONLY لتجنب ذلك. يبدو أن بعض الناس رأوا أنها فكرة جيدة ، لكن في هذه الحالة ربما أتعرض لتوضيح بشكل صريح IPV6_V6ONLY وترجمة NULL مباشرة الى 0.0.0.0 تجاوز getaddrinfo() آلية.