دوازده گام برای مهاجرت ISP ها به IPv6 (اینفوگرافیک)

در پست های متعددی سعی کردیم تا به طرق مختلف به معرفی روش های پرکاربردی که برای مهاجرت به IPv6 مورد استفاده قرار می گیرند، بپردازیم و از سوی دیگر سعی نمودیم تا در قالب اینفوگرافیکی پروتکل IPv6 را از دید تجاری و نه تخصصی، برای مدیران و عزیزانی که قصد شناخت این پروتکل را داشتند، معرفی نماییم. در این پست نیز، سعی نمودیم تا در قالب اینفوگرافیکی دیگر، مراحل و راهکارهای پیشنهادی برای مهاجرت ISP ها به IPv6 را بیان کنیم. برای سهولت دسترسی به مطالب ارائه شده‌ی قبلی در رابطه با راهکارهای عنوان شده در این اینفوگرافیک، می توانید از لینک های زیر استفاده نمایید:

نمونه ی با کیفیت این اینفوگرافیک را می توانید از طریق این لینک دریافت کنید. ادامه خواندن “دوازده گام برای مهاجرت ISP ها به IPv6 (اینفوگرافیک)”

مکانیزم های مهاجرت به IPv6: راهکار ۴۶۴XLAT

با استفاده از راهکار NAT64 دستگاه‌های موبایل IPv6-only توانایی برقراری ارتباط با سرورهای IPv4-only را داشتند. اما NAT64 به تنهایی جوابگوی نیازهای شبکه های موبایل نبود چرا که اکثر نرم‌افزارهای موبایل هم چنان بر مبنای IPv4 می باشند. به همین دلیل راهکار دیگری با نام ۴۶۴XLAT معرفی گردید.

با استفاده از این مکانیزم آدرس IPv4 آن دسته از کاربران (بیشتر موبایل و نرم‌افزارهای موبایلی) که IPv6 را پشتیبانی نمی کنند، توسط نرم‌افزاری با نام Customer-side Translator یا به اختصار CLAT، به یک آدرس IPv6 با mask ای خاص، /۹۶، ترجمه شده و پکت از طریق ساختار IPv6 به سمت PLAT یا Provider-site Translator ارسال می شود.

PLAT با گشودن پکت IPv6 به آدرس های Private IPv4 مبدا و مقصد داخل پکت دست یافته و پکت را به مقصد مورد نظر ارسال می کند. به عبارتی در این روش کلاینت و سرور فقط از طریق Private IPv4 خود در بستری مبتنی بر IPv6 می توانند با یکدیگر ارتباط برقرار نمایند.

روش ۴۶۴XLAT تنها از مدل های کلاینت-سروری پشتیبانی می کند و نمی‌توان از طریق آن یک ارتباط peer-to-peer بر اساس IPv4 Private را برقرار ساخت. ویدیوی زیر از RIPE NCC به تشریح عملکرد این مکانیزم می پردازد (به جهت سهولت دسترسی هم وطنان داخل کشور، این ویدیو در آپارات آپلود شده است).

ادامه خواندن “مکانیزم های مهاجرت به IPv6: راهکار ۴۶۴XLAT”

مکانیزم های مهاجرت به IPv6: راهکار NAT64

یکی از مشکلات بر سر راه Mobile Provider ها فراهم کردن شرایطی است که هاست های IPv6-only بتوانند با سرورهای IPv4-only ارتباط برقرار نمایند. NAT64 مکانیزمی است بر پایه ی Network Address Translation (NAT) که با نگاشت آدرس IPv6 هاست متصل به پروایدر به یک آدرس IPv4، این مشکل را برطرف می سازد. ادامه خواندن “مکانیزم های مهاجرت به IPv6: راهکار NAT64”

آشنایی با اصول اولیه ی IPv6 (اینفوگرافیک)

با کم رنگ شدن هر چه بیشتر IPv4 در سال های اخیر، نیاز سازمان ها برای مهاجرت به سمت استفاده از IPv6 هر روز پر رنگ تر می شود به گونه ای که این نیاز در آینده ای نه چندان دور به امری حیاتی برای بقای یک کسب و کار در بازار تجارت جهانی محسوب خواهد شد.

با این حال هنوز هم بسیاری از دستگاه ها در دنیای اینترنت هم چنان از IPv4 استفاده می کنند و بسیاری از کاربران با مفهوم IP آشنا نمی باشند.

اینفوگرافیگی که در ادامه آمده جهت آشنایی و کمک به افرادی تهیه شده است که شناخت چندانی از IP و ضرورت مهاجرت به IPv6 ندارند ولی این روزها بیش از پیش با این مفاهیم روبه رو می شوند. ادامه خواندن “آشنایی با اصول اولیه ی IPv6 (اینفوگرافیک)”

Dual-Stack Lite

در پست قبل معماری Large Scale NAT یا LSN، به همراه مشکلاتی که سر راه این معماری وجود داشت و همینطور راه حل هایی که برای حل این مشکلات قابل استفاده بودند، توضیح داده شد. خلاصه ای کوتاه از آن چه در پست قبل مطرح گردید به این صورت است که:

ساده ترین روش برای پیاده سازی LSN، بهره گیری از NAT444 بود که یکی از مشکلات سر راه این روش، احتمال ایجاد overlap بین آدرس های IP Private مشتریان و رنج آدرس IP های Private ای بود که ISP به لینک بین دستگاه خود و مشتری اختصاص داده بود.

مشکل بزرگ بعدی زمانی پیش می آمد که دو مشتری که هر دو با یک LSN ارتباط داشتند، قصد برقراری ارتباط با یکدیگر را داشته باشند. در این صورت چون آدرس Private به آدرس Public ای نگاشت نمی شد، احتمال drop شدن پکت ها از سوی دستگاه هایی که در لبه ی ساختار شبکه ی مشتری قرار داشتند، افزایش پیدا می کرد.

یکی از راه حل های پیشنهادی برای حل این مشکل آن بود که از یک بلوک از آدرس های IPv4 باقی مانده که با آدرس های RFC 1918 (یا همان آدرس های IPv4 Private) هم پوشانی نداشته باشند، به عنوان shared address  استفاده شوند و از این طریق هم مشکل هم پوشانی آدرس ها حل شود و هم از مشکل فیلتر شدن پکت های مشتریانی که در پشت یک LSN یکسان قرار دارند، جلوگیری گردد. اما این پیشنهاد تقریباً هیچ وقت عملیاتی نشد.

راه حل بعدی، استفاده از آدرس های IPv6 بین ISP و مشتریان، به جای آدرس IPv4 بود. در واقع استفاده از NAT464. این روش علاوه بر این که مشکلات NAT444 را حل می کرد، به Provider ها نیز این امکان را می داد که سریعتر به سمت معماری IPv6-only که مد نظر داشتند، حرکت کنند. سختی این روش آن بود که هم CPE NAT ( یا همان NAT سنتی مورد استفاده سمت ساختار مشتری) و هم معماری LSN، باید قابلیت ترجمه ی هردوی آدرس های IPv4 و IPv6 به یکدیگر را می داشتند که همین موضوع باعث ایجاد پیچیدگی و بروز مشکلات جدیدی در عملکرد، مقیاس پذیری و افزونگی می شد.

روشی که برای حل این مشکلات پیشنهاد شد، Dual-Stack Lite نام داشت. در این روش به لینک بین مشتری و ISP، فقط آدرس IPv6 اختصاص داده می شود. پکت IPv4 ای که از جانب ساختار مشتری بخواهد به مقصدی خارج از این ساختار ارسال شود، در یک پکت IPv6 کپسوله شده و به سمت Provider ارسال می شود. روتری که در لبه ی ساختار Provider قرار دارد، این پکت IPv6 را باز کرده و در قبال محتویات آن ( که در واقع یک پکت IPv4 است) از NAT44 استفاده می کند.

پس به این ترتیب با پیاده سازی یک تانل IPv4 بر روی لینک IPv6 بین ساختار مشتری و ISP، این هدف محقق می شود و علاوه بر این که پیاده سازی این تانل خیلی ساده تر از ترجمه ی آدرس هاست، نگرانی های مربوط به مباحث redundancy  و performance  هم برطرف می شوند.

در مقاله ی زیر سعی شده تا بیشتر با Dual-Stack Lite و انواع مدل های پیاده سازی آن آشنا شویم.

Understanding Dual-Stack Lite