اگر از پست قبل به خاطر داشته باشید، 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 ختم می گردد.
