IPv4 يعقد رمز التطبيق ويسبب تأثير البطارية
لا تزال معظم حركة المرور على الإنترنت اليوم تستخدم IPv4 ، والتي لا يمكن أن توفر اتصالًا شفافًا من طرف إلى طرف للتطبيقات. يوفر IPv4 فقط 232 العناوين – أقل بكثير من عدد الأجهزة على الإنترنت اليوم – لذلك لا يمكن تعيين عنوان IPv4 عام لكل جهاز Android ، ناهيك عن تطبيقات أو وظائف فردية داخل الجهاز. لذلك لدى معظم مستخدمي الإنترنت عناوين IPv4 الخاصة ، ومشاركة عنوان IPv4 العام مع مستخدمين آخرين من نفس الشبكة باستخدام ترجمة عنوان الشبكة (NAT). يجعل NAT من الصعب إنشاء تطبيقات شبكات متقدمة مثل تطبيقات الاتصال بالفيديو أو VPNs ، لأن هذه الأنواع من التطبيقات تحتاج إلى إرسال حزم بشكل دوري للحفاظ على جلسات NAT على قيد الحياة (التي تؤلم البطارية) وتنفيذ بروتوكولات معقدة مثل الصاعقة للسماح للأجهزة بالاتصال ببعضها البعض من خلال NAT.
لماذا لم يحل IPv6 هذه المشكلة بعد
يوفر الإصدار الجديد من بروتوكول الإنترنت ، IPv6 – الذي يستخدمه الآن حوالي نصف مستخدمي Google – مساحة عنوان غير محدودة تقريبًا وقدرة على استخدام الأجهزة لاستخدام عناوين متعددة. عندما يتمكن كل جهاز من الحصول على عناوين IPv6 العالمية ، لا توجد حاجة لاستخدام NAT لمشاركة العناوين! ولكن على الرغم من أن مساحة العنوان نفسها لم تعد محدودة ، إلا أن طرق تعيين عنوان IPv6 الحالية المستخدمة على Wi-Fi ، مثل SLAAC و DHCPv6 IA_NA ، لا تزال لها قيود.
لسبب واحد ، تتطلب كل من SLAAC و DHCPv6 IA_NA من الشبكة الحفاظ على الحالة لكل عنوان فردي ، وبالتالي فإن تعيين أكثر من عدد قليل من عناوين IPv6 لكل جهاز Android يمكن أن يتسبب في مشكلات التحجيم على الشبكة. هذا يعني أنه لا يمكن في كثير من الأحيان تعيين عناوين IPv6 إلى VMs أو الحاويات داخل الجهاز ، أو للأجهزة القابلة للارتداء والأجهزة المربوطة الأخرى المتصلة به. على سبيل المثال ، إذا كان تطبيقك يعمل على جهاز يمكن ارتداؤه متصلًا بهاتف Android ، أو على جهاز لوحي مرتبط بهاتف Android متصل بـ Wi-Fi ، فمن المحتمل ألا يكون له اتصال IPv6 وسيحتاج إلى التعامل مع التعقيدات وتأثير البطارية لـ NAT.
بالإضافة إلى ذلك ، سمعنا ملاحظات من بعض المستخدمين ومشغلي الشبكات أنهم يرغبون في مزيد من التحكم في عناوين IPv6 التي تستخدمها أجهزة Android. حتى الآن ، دعم Android فقط SLAAC ، والذي لا يسمح للشبكات بتعيين عناوين IPv6 يمكن التنبؤ بها ، ويجعل من الصعب تتبع التعيين بين عناوين IPv6 والأجهزة التي تستخدمها. وقد حد هذا من توفر IPv6 على أجهزة Android على بعض الشبكات.
الحل: كتل عنوان IPv6 المخصصة مع DHCPV6 PD
للتغلب على هذه العيوب ، أضفنا دعمًا لتفويض بادئة DHCPV6 (PD) على النحو المحدد في RFC 8415 و RFC 9762. يمكن الآن لمكدس شبكة Android أن يطلب الآن بادئة مخصصة من الشبكة ، وإذا حصلت على بادئة ، فسيستخدمها للحصول على اتصال IPv6. في الإصدارات المستقبلية ، سيتمكن الجهاز من مشاركة البادئة مع الأجهزة القابلة للارتداء ، والأجهزة المربوطة ، والأجهزة الافتراضية ، وشبكات الذروة مثل مؤشر الترابط ، وتوفير جميع هذه الأجهزة مع اتصال IPv6 العالمي. هذا يدرك حقًا إمكانات IPv6 للسماح بالاتصال الشامل والقابل للتطوير بعدد غير محدود من الأجهزة والوظائف ، دون الحاجة إلى NAT. ولأن الشبكة يتم تعيينها من قبل الشبكة ، يمكن لمشغلي الشبكة استخدام البنية التحتية لقطع تسجيل DHCPV6 الحالية لتتبع الجهاز الذي يستخدم أي بادئة (انظر RFC 9663 للحصول على إرشادات لمشغلي الشبكات على نشر DHCPV6 PD).
يتيح ذلك الشبكات إدراك إمكانات IPv6 تمامًا: تحافظ الأجهزة على مرونة SLAAC ، مثل القدرة على استخدام عدد غير محدود تقريبًا من العناوين ، وتحافظ الشبكة على إمكانية إدارة ومساءلة إعداد DHCPv6 التقليدي. نأمل أن يسمح هذا بمزيد من الشبكات بالانتقال إلى IPv6 ، وتزويد التطبيقات بتوصيل IPv6 من شوط إلى النهاية وتقليل الحاجة إلى اجتياز NAT و keepalives.
