ملاحظة
النشر والاختبار على الشبكة قيد التقدم. خاضع لتعديلات طفيفة.
نظرة عامة
يهدف هذا الاقتراح إلى تنفيذ تحسينات على وسائط النقل SSU وNTCP2 لدعم IPv6.
الدافع
مع تزايد انتشار IPv6 حول العالم، وشيوع الإعدادات التي تعتمد على IPv6 فقط (خاصةً على الأجهزة المحمولة)، نحتاج إلى تحسين دعمنا لبروتوكول IPv6 وإزالة الافتراضات القائلة بأن جميع الراوترات تدعم IPv4.
التحقق من الاتصال
عند اختيار الأقران للأنفاق، أو اختيار مسارات OBEP/IBGW لتوجيه الرسائل، يساعد حساب ما إذا كان يمكن للراوتر A الاتصال بالراوتر B. بشكل عام، يعني هذا تحديد ما إذا كان لدى A إمكانية إرسال خارجية عبر وسيلة نقل ونوع عنوان (IPv4/v6) يتطابق مع أحد عناوين B الواردة المعلنة.
ومع ذلك، في كثير من الحالات لا نعرف إمكانات A وعلينا افتراضات. إذا كان A مخفيًا أو خلف جدار ناري، فإن العناوين لا تُنشر، وليس لدينا معرفة مباشرة – لذلك نفترض أنه يدعم IPv4، ولا يدعم IPv6. الحل هو إضافة “مميزتين” جديدتين أو إمكانات (caps) إلى معلومات الراوتر (Router Info) للإشارة إلى القدرة على الإرسال الخارجي عبر IPv4 وIPv6.
مقدمو IPv6
تحتوي مواصفاتنا الخاصة بـ SSU على أخطاء وتناقضات حول ما إذا كانت مقدمو IPv6 مدعومين في حالات تقديم IPv4. على أي حال، لم يتم تنفيذ ذلك قط في Java I2P أو i2pd. يجب تصحيح هذا الأمر.
عمليات تقديم IPv6
توضح مواصفاتنا الخاصة بـ SSU بوضوح أن عمليات تقديم IPv6 غير مدعومة. وكان ذلك بناءً على افتراض أن IPv6 لا يكون أبدًا خلف جدار ناري. ومن الواضح أن هذا غير صحيح، ونحتاج إلى تحسين دعم الراوترات التي تعمل عبر IPv6 وراء جدار ناري.
مخططات التقديم
المفتاح: —– هو IPv4، ====== هو IPv6
حاليًا IPv4 فقط:
Alice Bob Charlie
RelayRequest ---------------------->
<-------------- RelayResponse RelayIntro ----------->
<-------------------------------------------- HolePunch
SessionRequest -------------------------------------------->
<-------------------------------------------- SessionCreated
SessionConfirmed ------------------------------------------>
Data <--------------------------------------------------> Data
تقديم عبر IPv4، مع مُقدِّم عبر IPv6:
Alice Bob Charlie
RelayRequest ======================>
<============== RelayResponse RelayIntro ----------->
<-------------------------------------------- HolePunch
SessionRequest -------------------------------------------->
<-------------------------------------------- SessionCreated
SessionConfirmed ------------------------------------------>
Data <--------------------------------------------------> Data
تقديم عبر IPv6، مع مُقدِّم عبر IPv6:
Alice Bob Charlie
RelayRequest ======================>
<============== RelayResponse RelayIntro ===========>
<============================================ HolePunch
SessionRequest ============================================>
<============================================ SessionCreated
SessionConfirmed ==========================================>
Data <==================================================> Data
تقديم عبر IPv6، مع مُقدِّم عبر IPv4:
Alice Bob Charlie
RelayRequest ---------------------->
<-------------- RelayResponse RelayIntro ===========>
<============================================ HolePunch
SessionRequest ============================================>
<============================================ SessionCreated
SessionConfirmed ==========================================>
Data <==================================================> Data
التصميم
توجد ثلاث تغييرات يجب تنفيذها.
- إضافة الميزتين “4” و"6" إلى خصائص إمكانات عنوان الراوتر (Router Address capabilities) للإشارة إلى دعم الإرسال الخارجي عبر IPv4 وIPv6
- إضافة دعم لتقديم IPv4 عبر مقدمي IPv6
- إضافة دعم لتقديم IPv6 عبر مقدمي IPv4 وIPv6
المواصفات
الميزات 4/6
تم تنفيذ هذا في الأصل دون اقتراح رسمي، لكنه مطلوب لدعم تقديم IPv6، لذا ندرجها هنا.
يتم تعريف ميزتين جديدتين “4” و"6". ستُضاف هاتان الميزتان الجديدتان إلى خاصية “caps” في عنوان الراوتر (Router Address)، وليس في ميزات معلومات الراوتر (Router Info caps). حاليًا لا نملك خاصية “caps” معرّفة لـ NTCP2. عنوان SSU مع مقدمين (introducers) هو، بحكم التعريف، IPv4 حاليًا. ولا ندعم تقديم IPv6 على الإطلاق. ومع ذلك، فإن هذا الاقتراح متوافق مع تقديم IPv6. انظر أدناه.
بالإضافة إلى ذلك، قد يدعم الراوتر الاتصال عبر شبكة تراكب مثل I2P-over-Yggdrasil، لكنه لا يرغب في نشر عنوان، أو أن هذا العنوان ليس له تنسيق قياسي IPv4 أو IPv6. يجب أن تكون هذه المنظومة الجديدة للميزات مرنة بما يكفي لدعم هذه الشبكات أيضًا.
نعرّف التغييرات التالية:
NTCP2: إضافة الخاصية “caps”
SSU: إضافة دعم لعنوان راوتر بدون “host” أو “introducers”، للإشارة إلى دعم الإرسال الخارجي لـ IPv4 أو IPv6 أو كليهما.
كلا الوسائط: تحديد القيم التالية لـ caps:
- “4”: دعم IPv4
- “6”: دعم IPv6
قد تدعم قيمة واحدة أو أكثر في عنوان واحد. انظر أدناه. يجب تضمين واحدة على الأقل من هذه الميزات إذا لم تُضَف قيمة “host” في عنوان الراوتر. يُسمح بحد أقصى ميزة واحدة من هذه الميزات إذا كانت قيمة “host” موجودة في عنوان الراوتر. قد تُعرّف ميزات وسائط نقل إضافية في المستقبل للإشارة إلى دعم شبكات التراكب أو وسائط اتصال أخرى.
حالات الاستخدام والأمثلة
SSU:
SSU مع host: 4/6 اختيارية، ولا تزيد أبدًا عن واحدة. مثال: SSU caps=“4” host=“1.2.3.4” key=… port=“1234”
SSU للإرسال الخارجي فقط لأحد البروتوكولين، والآخر مُعلن: فقط caps، 4 أو 6. مثال: SSU caps=“6”
SSU مع مقدمين: لا تُدمج أبدًا. مطلوبة إما 4 أو 6. مثال: SSU caps=“4” iexp0=… ihost0=… iport0=… itag0=… key=…
SSU مخفي: فقط caps، 4 أو 6 أو 46. يُسمح بقيم متعددة. لا حاجة لعنوانين، واحد بـ 4 وآخر بـ 6. مثال: SSU caps=“46”
NTCP2:
NTCP2 مع host: 4/6 اختيارية، ولا تزيد أبدًا عن واحدة. مثال: NTCP2 caps=“4” host=“1.2.3.4” i=… port=“1234” s=… v=“2”
NTCP2 للإرسال الخارجي فقط لأحد البروتوكولين، والآخر مُعلن: caps، s، v فقط، 4/6/y، يُسمح بقيم متعددة. مثال: NTCP2 caps=“6” i=… s=… v=“2”
NTCP2 مخفي: caps، s، v فقط 4/6، يُسمح بقيم متعددة. لا حاجة لعنوانين، واحد بـ 4 وآخر بـ 6. مثال: NTCP2 caps=“46” i=… s=… v=“2”
مقدمو IPv6 لتقديم IPv4
تتطلب التغييرات التالية تصحيح الأخطاء والتناقضات في المواصفات. كما وصفنا هذا بأنه “الجزء 1” من الاقتراح.
تغييرات المواصفات
تقول مواصفات SSU حاليًا (ملاحظات IPv6):
تم دعم IPv6 بدءًا من الإصدار 0.9.8. يمكن أن تكون عناوين الترحيل المنشورة إما IPv4 أو IPv6، ويمكن أن تكون الاتصالات بين Alice وBob عبر IPv4 أو IPv6.
أضف ما يلي:
بينما تم تغيير المواصفات بدءًا من الإصدار 0.9.8، لم يتم دعم الاتصالات بين Alice وBob عبر IPv6 فعليًا حتى الإصدار 0.9.50. كانت إصدارات Java routers السابقة تنشر خطأً الميزة ‘C’ للعناوين IPv6، رغم أنها لم تُستخدم فعليًا كمُقدِّم عبر IPv6. لذلك، يجب على الراوترات الوثوق فقط بالميزة ‘C’ على عنوان IPv6 إذا كان إصدار الراوتر 0.9.50 أو أعلى.
تقول مواصفات SSU حاليًا (طلب الترحيل - Relay Request):
يتم تضمين عنوان IP فقط إذا كان مختلفًا عن عنوان المصدر والمنفذ الخاص بالحزمة. في التنفيذ الحالي، يكون طول IP دائمًا 0 والمنفذ دائمًا 0، وينبغي على المستقبل استخدام عنوان المصدر والمنفذ الخاص بالحزمة. يمكن إرسال هذه الرسالة عبر IPv4 أو IPv6. إذا كانت عبر IPv6، يجب على Alice تضمين عنوانها وميناء IPv4.
أضف ما يلي:
يجب تضمين عنوان IP والمنفذ لتقديم عنوان IPv4 عند إرسال هذه الرسالة عبر IPv6. يتم دعم ذلك بدءًا من الإصدار 0.9.50.
تقديم IPv6
تحتوي جميع رسائل الترحيل الثلاث في SSU (RelayRequest، RelayResponse، وRelayIntro) على حقول طول IP لإظهار طول عنوان IP (Alice أو Bob أو Charlie) الذي يليه.
وبالتالي، لا يتطلب الأمر أي تغيير في تنسيق الرسائل. فقط تغييرات نصية في المواصفات، تشير إلى أن عناوين IP ذات 16 بايت مسموح بها.
التغييرات التالية مطلوبة في المواصفات. كما وصفنا هذا بأنه “الجزء 2” من الاقتراح.
تغييرات المواصفات
تقول مواصفات SSU حاليًا (ملاحظات IPv6):
الاتصال بين Bob وCharlie وبين Alice وCharlie يتم عبر IPv4 فقط.
تقول مواصفات SSU حاليًا (طلب الترحيل - Relay Request):
لا توجد خطط لتنفيذ الترحيل عبر IPv6.
غيّر ليصبح:
تم دعم الترحيل عبر IPv6 بدءًا من الإصدار 0.9.xx
تقول مواصفات SSU حاليًا (استجابة الترحيل - Relay Response):
يجب أن يكون عنوان IP الخاص بـ Charlie عنوان IPv4، لأنه هو العنوان الذي سترسل إليه Alice رسالة SessionRequest بعد Hole Punch. لا توجد خطط لتنفيذ الترحيل عبر IPv6.
غيّر ليصبح:
يمكن أن يكون عنوان IP الخاص بـ Charlie عنوان IPv4 أو، بدءًا من الإصدار 0.9.xx، عنوان IPv6. هذا هو العنوان الذي سترسل إليه Alice رسالة SessionRequest بعد Hole Punch. تم دعم الترحيل عبر IPv6 بدءًا من الإصدار 0.9.xx
تقول مواصفات SSU حاليًا (تقديم الترحيل - Relay Intro):
عنوان IP الخاص بـ Alice دائمًا 4 بايت في التنفيذ الحالي، لأن Alice تحاول الاتصال بـ Charlie عبر IPv4. يجب إرسال هذه الرسالة عبر اتصال IPv4 مُنشأ، لأن هذه هي الطريقة الوحيدة التي يعرف بها Bob عنوان IPv4 الخاص بـ Charlie لإعادته إلى Alice في رسالة RelayResponse.
غيّر ليصبح:
بالنسبة لـ IPv4، يكون عنوان IP الخاص بـ Alice دائمًا 4 بايت، لأن Alice تحاول الاتصال بـ Charlie عبر IPv4. بدءًا من الإصدار 0.9.xx، تم دعم IPv6، ويمكن أن يكون عنوان IP الخاص بـ Alice 16 بايت.
بالنسبة لـ IPv4، يجب إرسال هذه الرسالة عبر اتصال IPv4 مُنشأ، لأن هذه هي الطريقة الوحيدة التي يعرف بها Bob عنوان IPv4 الخاص بـ Charlie لإعادته إلى Alice في رسالة RelayResponse. بدءًا من الإصدار 0.9.xx، تم دعم IPv6، ويمكن إرسال هذه الرسالة عبر اتصال IPv6 مُنشأ.
أضف أيضًا:
بدءًا من الإصدار 0.9.xx، يجب أن يحتوي أي عنوان SSU منشور مع مقدمين على “4” أو “6” في خيار “caps”.
الهجرة
يجب على جميع الراوترات القديمة تجاهل الخاصية caps في NTCP2، وتجاهل أحرف الميزات غير المعروفة في خاصية caps الخاصة بـ SSU.
يُفترض أن أي عنوان SSU مع مقدمين لا يحتوي على ميزة “4” أو “6” هو مخصص لتقديم IPv4.