در پست قبل معماری 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
