IPv6 حالا بیش از ۵۰٪ ترافیک جهانی اینترنت را حمل میکند — این آستانه واقعاً چه چیزی را تغییر میدهد
نشان ۵۰٪ یک نقطه عطف نیست، یک نقطه تحول است
ردیاب آمار IPv6 گوگل در اوایل مه ۲۰۲۶ از ۵۰٪ عبور کرد، رقمی که نشاندهنده سهم کاربرانی است که از طریق IPv6 به گوگل میرسند نه IPv4. اندازهگیریهای موازی Akamai ترافیک جهانی IPv6 را ۵۲–۵۴٪ از کل بایتهای ارسالی قرار میدهد. این اعداد مهم هستند چون لحظهای را نشان میدهند که IPv6 دیگر پروتکل اقلیت در کنار IPv4 نیست و به پروتکلی تبدیل میشود که باید به صورت بومی از آن پشتیبانی کنید، نه به عنوان یک فکر بعدی.
این انتقال از نظر فنی از اواخر دهه ۱۹۹۰ ممکن بوده، از ۱۹۹۸ با RFC 2460 استاندارد شده، و در هر کنفرانس مهندسی شبکه در پانزده سال گذشته «فوری» اعلام شده است. تمام شدن آدرسهای IPv4 با دقت بالایی توسط محققان ARIN و APNIC پیشبینی شده بود، اما مهاجرت بسیار کند پیش رفت. چه چیزی تغییر کرد؟ سه چیز به هم پیوستند: شبکههای موبایل، فشار ابرغولها (hyperscaler)، و depletion بازار آدرسهای IPv4.
چرا شبکههای موبایل باعث نقطه تحول شدند
T-Mobile USA از ۲۰۲۱ یک شبکه موبایل تقریباً تمام IPv6 دارد. جیو در هند که به تنهایی به بیش از ۴۵۰ میلیون مشترک خدمات میدهد، IPv6-only را برای کل stack LTE/5G خود مستقر کرد. وقتی یک اپراتور واحد که میلیاردها اتصال روزانه را مدیریت میکند به IPv6-first سوئیچ کند، آمار جهانی به طور محسوسی تغییر میکند. Verizon و AT&T نیز با سهم ترافیک IPv6 بالای ۷۰٪ در شبکههای موبایل خود تا ۲۰۲۴ دنبال کردند.
محرک اقتصادی ساده است. آدرسهای IPv4 در بازار ثانویه اکنون به قیمت ۴۵–۵۵ دلار به ازای هر آدرس معامله میشوند، با بلاکهای /24 (۲۵۶ آدرس) که بیش از ۱۲٬۰۰۰ دلار فروخته میشوند. یک اپراتور موبایل که به هر دستگاه یک آدرس IPv4 عمومی اختصاص دهد باید صدها میلیون دلار برای موجودی آدرس خرج کند. IPv6 با فضای آدرس ۱۲۸ بیتی که ۳.۴ × 10^38 آدرس ارائه میدهد، آن هزینه را کاملاً حذف میکند — هر دستگاه یک آدرس globally routable بدون NAT، بدون پیچیدگی carrier-grade NAT (CGNAT) و بدون سربار تاخیری که CGNAT ایجاد میکند.
IPv6 واقعاً چه چیزی را برای تیمهای زیرساخت تغییر میدهد
برای اپراتورهای شبکهای که dual-stack کار میکنند (IPv4 و IPv6 همزمان)، سوال فوری این است که آیا میتوانند شروع به از رده خارج کردن زیرساخت IPv4 کنند. پاسخ ظریف است اما در زمینههای خاص به سمت بله حرکت میکند.
شبکههای تحویل محتوا مانند Cloudflare و Fastly در حال حاضر بیشتر ترافیک خود را از طریق IPv6 ارائه میدهند جایی که کلاینتها از آن پشتیبانی کنند. دادههای ۲۰۲۵ Cloudflare نشان داد ۵۶٪ از اتصالات HTTP/3 از طریق IPv6 وارد میشود. برای این اپراتورها، IPv4 به fallback تبدیل شده است، نه مسیر اصلی.
دیتاسنترها و ارائهدهندگان ابر محافظهکارتر هستند. AWS، Azure و GCP هنوز برای بیشتر سرویسها پیشفرض IPv4 هستند، اگرچه هر سه اکنون برای تخصیص آدرس IPv4 هزینه دریافت میکنند — AWS از فوریه ۲۰۲۴ به ازای هر آدرس IPv4 عمومی ۰.۰۰۵ دلار در ساعت شارژ کرد. Azure با قیمتگذاری مشابه در ۲۰۲۵ دنبال کرد. این هزینهها تیمهای سازمانی را به ممیزی استفاده IPv4 و مهاجرت سرویسهای داخلی به IPv6 سوق میدهد.
WAN سازمانی همچنان عقبمانده است. پلتفرمهای قدیمی SD-WAN، فایروالهای on-premises از فروشندگانی مانند Cisco و Fortinet، و قراردادهای MPLS که سالها پیش مذاکره شدهاند اغلب پشتیبانی محدود یا تست نشده IPv6 دارند. یک نظرسنجی ۲۰۲۵ از سوی Internet Society نشان داد که ۳۸٪ از مهندسان شبکه سازمانی «شکافهای پشتیبانی فروشنده» را مانع اصلی خود برای استقرار IPv6 ذکر کردند.
پل NAT64 و محدودیتهای عملی آن
شبکههایی که IPv6-only کار میکنند — به ویژه اپراتورهای موبایل — از NAT64 و DNS64 برای ترجمه درخواستهای کلاینت IPv6 به مقصدهای IPv4 استفاده میکنند. این برای بیشتر ترافیک وب خوب کار میکند اما چند کاربرد را خراب میکند:
- برنامههایی که آدرسهای IPv4 را به صورت خام در کد خود جاسازی میکنند به جای استفاده از DNS resolution
- برخی کلاینتهای VPN که نقاط پایانی تونل IPv4 را فرض میکنند
- Firmware قدیمی اینترنت اشیا که فاقد پیادهسازی stack IPv6 است
- برخی پروتکلهای peer-to-peer که مذاکره آدرس IPv4 را hardcode کردهاند
از سال ۲۰۱۶، اپ استور اپل از برنامهها خواسته است که به درستی روی شبکههای IPv6-only کار کنند که بدترینها را در iOS فیلتر کرد. اجرای مشابه در اندروید ضعیفتر بوده، هرچند گوگل از ۲۰۲۴ سازگاری IPv6 را برای برنامههای Play Store الزامی کرد. برنامههای سازمانی — به ویژه ابزارهای داخلی سفارشیسازی شده — همچنان مشکلسازترین دسته باقی میمانند.
پیامدهای امنیتی که اغلب نادیده گرفته میشوند
وضعیت امنیتی شبکههای IPv6 با IPv4 به شیوههایی متفاوت است که تیمها را غافلگیر میکند. چندین قانون فایروال که برای محدودههای آدرس IPv4 نوشته شدهاند در سازمانهایی که IPv6 را بدون بهروزرسانی سیاستهای امنیتی مستقر کردهاند، معادل IPv6 ندارند. مشاوره ۲۰۲۴ CISA درباره امنیت IPv6 خاطرنشان کرد که در تستهای نفوذ، رابطهای IPv6 در ۲۳٪ مواردی که IPv4 به درستی مسدود شده بود از شبکههای بیرونی قابل دسترسی بودند — چون آدرس IPv6 اصلاً در قوانین فایروال گنجانده نشده بود.
ICMPv6 بخش جداییناپذیرتری از IPv6 است نسبت به ICMP برای IPv4. پروتکل کشف همسایه (NDP) که جایگزین ARP میشود از ICMPv6 استفاده میکند و نباید به طور کامل مسدود شود. تیمهایی که از IPv4 مهاجرت میکنند و به طور بازتابی همه ICMP را مسدود میکنند، شبکه خودشان را خراب میکنند. حملات NDP spoofing (معادل ARP poisoning در IPv6) نیز نیاز به mitigations خاصی مانند RA Guard و SEND دارند که بسیاری از تیمهای شبکه هنوز مستقر نکردهاند.
توسعهدهندگان باید چه کار متفاوتی انجام دهند
برای توسعهدهندگان برنامه، آستانه ۵۰٪ یک سیگنال واضح برای ممیزی مدیریت IPv6 در کدشان است. حوزههای خاصی که معمولاً خراب میشوند:
Socket binding: کدی که به 0.0.0.0 (wildcard IPv4) متصل میشود اتصالات IPv6 را نخواهد پذیرفت مگر اینکه سیستمعامل IPv6 را به طور خودکار به IPv4 نگاشت کند. در لینوکس، :: (wildcard IPv6) معمولاً هر دو را از طریق dual-stack sockets میپذیرد، اما این رفتار وابسته به پلتفرم است. راه حل مدیریت صریح dual-stack socket یا اتصال به :: با IPV6_V6ONLY روی false است.
تجزیه و اعتبارسنجی آدرس IP: هر کدی که آدرسهای IP را با استفاده از الگوهای regex نوشته شده برای IPv4 اعتبارسنجی یا تجزیه کند، آدرسهای IPv6 معتبر را رد خواهد کرد. کتابخانههایی مانند ماژول ipaddress پایتون یا بسته net گو هر دو را به درستی مدیریت میکنند؛ نوشتن parser IPv4-only خودتان در ۲۰۲۶ یک نقص محسوب میشود.
لاگگیری و analytics: آدرسهای IPv6 بلندتر هستند و از نشانهگذاری متفاوتی استفاده میکنند. پارسرهای لاگ، pipelineهای analytics و ابزارهای SIEM که برای IPv4 ساخته شدهاند، آدرسهای IPv6 را بیصدا حذف یا اشتباه تجزیه میکنند. این بر تشخیص تهدید، محدودیت نرخ و lookup جغرافیایی IP تأثیر میگذارد.
نکات عملی
- سرویسهای عمومی خود را از نظر دسترسی IPv6 با ابزاری مانند
test-ipv6.comیاipv6-test.comممیزی کنید. اگر سرور وب شما از طریق IPv6 قابل دسترسی نیست، اکنون در اقلیت هستید. - قوانین فایروال خود را از نظر کامل بودن IPv6 بررسی کنید. هر ACL IPv4 باید معادل IPv6 داشته باشد. یک اسکن پورت از یک میزبان IPv6-only علیه زیرساخت خود اجرا کنید.
- هزینه IPv4 ابر را مرور کنید. AWS و Azure اکنون برای آدرسهای IPv4 عمومی هزینه دریافت میکنند. یک ممیزی سیستماتیک از تخصیصهای IPv4 استفاده نشده یا کم استفاده معمولاً ۲۰–۴۰٪ را پیدا میکند که میتوانند آزاد یا با گزینههای IPv6 جایگزین شوند.
- برنامههای خود را روی شبکههای IPv6-only با استفاده از Network Link Conditioner مک تنظیم شده روی IPv6-only، یا یک دستگاه اندروید روی شبکه NAT64 تست کنید. این مشکلات را قبل از اینکه کاربران شما ببینند آشکار میکند.
- pipelineهای تجزیه لاگ و analytics را برای مدیریت نشانهگذاری آدرس IPv6 بهروزرسانی کنید. بررسی کنید که WAF، rate limiter و سرویسهای geo-IP شما آدرسهای IPv6 را به درستی پردازش کنند.