مکانیزم های مهاجرت به 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؛ مزایا و تصورات اشتباه

در نوشته ها و گفته های متعدد در رابطه با IPv6 با این عبارت روبه رو می شویم که:

‏IPv6‎‏ عملکرد بهتری نسبت به ‏IPv4‎‏ دارد.

و گاهی ‏در پی این عبارت دلایلی نیز آورده می شود. اما چه میزان این مطلب و دلایلی که در پی آن به عنوان مواردی برای ‏بهبود عملکرد ‏IPv6‎‏ مطرح می شوند، صحت دارند؟ ‏بیان بسیاری از این دلایل شاید تنها در وجهه‌ی عمومی و همراه ساختن عموم جامعه در حرکت به سمت استفاده از IPv6 قانع‌کننده و مقبول باشند اما از لحاظ فنی این انتظار وجود دارد که یک کارشناس حوزه‌ی اینترنت، توانایی استدلال در رد یا قبول هر یک از دلایلی که در پی این عبارت مطرح می شوند را داشته باشد. در این مقاله قصد داریم تا نگاهی فنی تر به این دلایل داشته باشیم.

***

در IPv6 انجام تغییراتی در ساختار و قالب این پروتکل سبب ایجاد بهبود کارایی آن در برخی موارد گشته که عبارتند از:

۱-‏ فضای آدرس دهی بسیار بزرگتر
اولین مزیتی که برای ‏IPv6‎‏ ‏ بیان می شود آن است که ‏IPv6‎‏ فضای آدرس دهی بزرگتری نسبت به ‏IPv4‎‏ ‏داشته و به همین دلیل می تواند تعداد آدرس های بیشتری را فراهم آورد. بله این عبارت درست است! ‏IPv6‎‏ ‏به دلیل ۱۲۸ بیتی بودن قادر است تقریبا ‏‎۳٫۴*۱۰^۳۸‎‏ آدرس ممکن را فراهم کند که با گسترش شبکه ها ‏و افزایش دستگاه هایی که توانایی اتصال به اینترنت را دارند، این مقدار آدرس ‏IP‏ تا مدت های زیادی ‏جوابگوی نیازها خواهد بود. اما این موضوع چه ارتباطی با بهبود عملکرد ‏IPv6‎‏ ‏دارد؟

تصور کنید آنقدر آدرس ‏IP‏ وجود دارد که هر دستگاه می تواند Public IP (آدرس عمومی اینترنی) متعلق به خود را داشته ‏باشد. دقت کنید که گفته شد آدرس Public IP‏. بله دقیقا منظور آدرس های ‏IP‏ ای هستند که در دنیای اینترنت ‏قابل مسیریابی می باشند. به نظر شما زمانی که هر دستگاه بتواند یک آدرس ‏Public IP مخصوص به خود ‏داشته باشد و خود به صورت مستقیم به اینترنت متصل گردد، چه مزیتی وجود خواهد داشت؟

برای رسیدن به جواب این سوال، به چندین سال قبل، زمانی که برای اولین بار احساس شد که آدرس های عمومیِ ‏IPv4‏ رو به اتمام هستند، باز می گردیم. در آن زمان اولین راهکاری که برای نجات ‏IPv4‎‏ ‏از این ‏اوضاع مطرح شد، راهکاری به اسم ‏Network Address Translation‏ یا همان ‏NAT‏ بود.

عملی که این ‏راهکار انجام می داد آن بود که دستگاه‌هایی که در داخل یک ساختار (مثلا دستگاه های داخل یک سازمان یا ‏دستگاه های داخل خانه و یا …) قرار داشتند، برای آن که بتوانند با هم ارتباط برقرار نمایند، از آدرس هایی ‏استفاده می کردند معروف به Private IPv4 (‏RFC1918‎‏) که این آدرس ها در اینترنت قابل مسیریابی نبودند و اگر قرار بود این دستگاه ها به اینترنت متصل ‏شوند و با سایر دستگاه ها در دنیای اینترنت ارتباط داشته باشند، Private IP‏ آن ها توسط ‏gateway‏ آن ساختار (مثلا مودم یا روتر) به یک Public IP‏ ترجمه می شد. به این ترتیب دیگر ‏نیازی نبود که همه‌ی دستگاه های درون یک ساختار یک IP آدرس ‏Public‏ مجزا و مخصوص به خود داشته ‏باشند، بلکه کافی بود به کل ساختاری که دستگاه ها در آن قرار داشتند تنها یک آدرس ‏عمومی IPv4 تعلق ‏گیرد و هر دستگاهی که قصد برقراری ارتباط با اینترنت را داشت، آدرس ‏Private‏ آن به آدرس ‏Public‏ ‏اختصاص یافته به ساختار ترجمه می گشت. ‏ ادامه خواندن “زوایای پنهان عملکرد IPv6؛ مزایا و تصورات اشتباه”

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

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

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

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

مفهوم Carrier Grade NAT (CGN)

اگر از پست قبل به خاطر داشته باشید، Dual Stack ساده ترین روش برای حرکت به سمت استفاده از IPv6 بود. در این روش، در صورتی که در یک ساختار IPv6، تمام دستگاه ها قابلیت پشتیبانی از هر دوی ورژن های IPv4/IPv6 را داشته باشند قادر خواهند بود تا با هر مقصدی؛ چه IPv4 و چه IPv6؛ ارتباط برقرار نمایند. این روش زمانی که اکثر کاربران هنوز در حال استفاده از IPv4 باشند، روش مناسبی است.

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

در گذشته برای کاهش نیاز به آدرس های IPv4 Public عموما از دو روش استفاده می شد:

  • یکی از راه ها استفاده از DHCP بود که شاید در آن زمان که تعداد دستگاه هایی که باید به صوت همزمان آنلاین می بودند، کم بود، روش موفقی محسوب می شد اما در حال حاضر که تعداد بیشماری دستگاه وجود دارد که همه همزمان آنلاین هستند، روش خوبی تلقی نمی شود.
  • راه حل بعدی استفاده از NAT44 بود که در واقع نگاشتی را بین آدرس های IPv4 Private، به یک آدرس IPv4 Public انجام می داد و به این ترتیب برای سازمان ها این امکان فراهم می شد که برای ارتباطات دستگاه های داخلی خود از آدرس های IPv4 Private استفاده کنند و اگر نیازی به ارتباط با اینترنت بود، از NAT استفاده می شد و نیاز به آدرس IPv4 Public کاهش پیدا می کرد.

اما این روش هم مشکلی مشابه روش استفاده از DHCP داشت. تعداد آدرس های IPv4 Public محدود بودند و اگر همزمان تعداد زیادی دستگاه نیاز به اتصال به اینترنت داشتند، این روش جوابگو نبود. بنابراین عملکرد NAT44 به گونه ای تغییر داده شد که از شماره پورت ها در هنگام نگاشت آدرس ها استفاده شود. همانطور که می دانید مشهورترین اصطلاح برای این روش Port Address Translation  یا PAT بود که اکنون دیگر PAT یک روش جداگانه محسوب نمی شود و تبدیل به عملکرد نرمال NAT44 گشته است.

اول این مبحث مطرح شد که روش Dual Stack در واقع مشکل IPv4 را حل نمی کرد چراکه نیاز به آدرس های IPv4 Public به تعداد زیاد، داخل Service Provider ها هم چنان وجود داشت و سپس همانطور که مطرح شد عملی که NAT انجام می داد آن بود که به شما این امکان را می داد که در داخل ساختار از آدرس های IPv4 Private استفاده کنید و بعد با داشتن چند آدرس محدود Public و استفاده از NAT، بین این آدرس ها نگاشت انجام دهید. پس آیا امکان پذیر نیست که ایده ی استفاده از NAT به داخل سرویس پروایدرها منتقل شود؟

در این مقاله به مسایلی که به آن ها اشاره شد پرداخته می شود و نهایتا به معرفی راهکار Carrier Grade NAT یا CGN ختم می گردد.

Understanding Carrier Grade NAT