IPv۶ چیست؟ راهنمای هاست، DNS و مهاجرت بدون اختلال

IPv6 فقط «آدرس‌های خیلی بیشتر» نیست؛ برای مدیر یک وب‌سایت، یک مسیر تحویل دوم است که از DNS و CDN تا Load Balancer، فایروال، وب‌سرور، لاگ و مانیتورینگ امتداد دارد. اگر رکورد AAAA را زودتر از آماده‌شدن این زنجیره منتشر کنید، سایت ممکن است برای شما سالم و برای بخشی از کاربران کند یا خارج از دسترس باشد.

برای بیشتر سایت‌های ایرانی، مهاجرت کم‌ریسک به معنی حذف فوری IPv4 نیست. الگوی عملی معمولاً Dual‑Stack است: A و AAAA هم‌زمان ارائه می‌شوند، هر خانواده جدا آزمون می‌شود و Rollback از قبل تعریف دارد. این راهنما تصمیم، معماری، امنیت، تست و اجرای مرحله‌ای IPv6 را بدون ادعای «سرعت یا امنیت خودکار» توضیح می‌دهد.

IPv6 چیست و چرا به وجود آمد؟

IPv4 از آدرس‌های ۳۲ بیتی استفاده می‌کند؛ در سطح نظری ۲ به توان ۳۲ یا حدود ۴.۲۹ میلیارد مقدار که همه آن‌ها نیز برای تخصیص عمومی آزاد نیستند. رشد اینترنت، موبایل، مراکز داده و دستگاه‌های متصل، کمبود آدرس عمومی و اتکای گسترده به سازوکارهای ترجمه آدرس را به مسئله‌ای ساختاری تبدیل کرد.

IPv6 اندازه آدرس را به ۱۲۸ بیت افزایش می‌دهد. استاندارد IPv6 در RFC ۸۲۰۰ علاوه بر فضای آدرس، هدر پایه، Extension Header، Flow Label و ملاحظات اندازه Packet را تعریف می‌کند. قالب و دامنه انواع آدرس نیز در معماری آدرس‌دهی RFC ۴۲۹۱ آمده است.

یک IPv4 مستنداتی می‌تواند 192.0.2.10 و یک IPv6 مستنداتی 2001:db8::10 باشد. علامت :: یک دنباله از گروه‌های صفر را کوتاه می‌کند و در هر آدرس فقط یک‌بار قابل استفاده است. این کوتاه‌نویسی را هنگام مقایسه رشته‌ای یا ساخت Regex فراموش نکنید؛ دو نمایش متنی متفاوت ممکن است به یک آدرس واحد اشاره کنند.

تفاوت IPv4 و IPv6 در یک نگاه

IPv6 نسخه «سریع‌تر و امن‌ترِ تضمینی» IPv4 نیست. کیفیت Route و Peering، پیاده‌سازی سیستم‌عامل، سیاست فایروال، MTU و آمادگی ارائه‌دهنده تعیین می‌کنند مسیر واقعی چه کیفیتی داشته باشد.

انواع آدرس IPv6 و Prefix را درست بشناسید

Prefix مانند 2001:db8:1234:10::/64 یک شبکه را توصیف می‌کند، نه یک Host منفرد. ارائه‌دهنده ممکن است یک آدرس، یک Subnet یا Prefix قابل Route تحویل دهد. Gateway، Route، شیوه تخصیص و پایداری Prefix را مکتوب بگیرید؛ حدس‌زدن /64 یا Gateway از روی نمونه‌های اینترنتی می‌تواند سرور را از دسترس خارج کند.

برای سرویس عمومی، DNS باید به آدرس پایدار و مدیریت‌شده اشاره کند. Privacy addressهای موقت برای کاهش قابلیت ردیابی اتصال خروجی Client طراحی شده‌اند؛ RFC 8981 این آدرس‌های موقت را توضیح می‌دهد. آن‌ها را با آدرس پایدار Listener عمومی اشتباه نگیرید و در تحلیل امنیتی نیز انتظار نداشته باشید هر کاربر همیشه یک IP ثابت داشته باشد.

آیا IPv6 سریع‌تر از IPv4 است؟

نه به‌صورت ذاتی. مسیر IPv6 ممکن است Peering مستقیم‌تر و تأخیر کمتر داشته باشد؛ مسیر دیگر ممکن است طولانی‌تر، کم‌ظرفیت‌تر یا ناپایدار باشد. حذف یک لایه ترجمه آدرس نیز الزاماً به بهبود قابل‌سنجش TTFB یا Core Web Vitals منجر نمی‌شود.

کلاینت‌های Dual‑Stack معمولاً فقط منتظر یک خانواده نمی‌مانند. Happy Eyeballs نسخه ۲ در RFC ۸۳۰۵ مدیریت پاسخ‌های A/AAAA و تلاش‌های اتصال را طوری توصیف می‌کند که خرابی یک مسیر کمتر به کاربر آسیب بزند. اما این سازوکار مجوز انتشار AAAA خراب نیست: Delay جایگزینی، تفاوت پیاده‌سازی Client و خرابی‌های نیمه‌کاره هنوز تجربه را بد می‌کنند.

مقایسه را با DNS lookup، TCP connect، TLS handshake، TTFB، نرخ موفقیت و p95 هر خانواده انجام دهید. اگر فقط میانگین کل را ببینید، ممکن است بهبود IPv4 افت IPv6 را پنهان کند.

آیا IPv6 به‌طور پیش‌فرض امن‌تر است؟

خیر. IPv6 امکان استفاده از IPsec را دارد، ولی تمام ترافیک را خودکار رمزنگاری نمی‌کند. HTTPS/TLS، مدیریت گواهی، وصله، احراز هویت و امنیت اپلیکیشن همچنان لازم‌اند. وجود NAT نیز فایروال نیست و حذف NAT هم به معنی حذف کنترل Stateful نیست.

مدل تهدید باید دو مسیر را ببیند: ممکن است SSH روی IPv4 بسته و روی IPv6 ناخواسته باز باشد؛ WAF فقط ترافیک Edge را تحلیل کند اما Origin با IPv6 مستقیم در دسترس بماند؛ یا Rate limit تک-IP با چرخش آدرس‌های یک Prefix بی‌اثر شود. RFC ۹۰۹۹ درباره امنیت عملیاتی شبکه‌های IPv6 نیز بر برنامه امنیتی جامع، نه یک قابلیت پروتکل، تأکید دارد.

رکورد A و AAAA چه تفاوتی دارند؟

• A: نام میزبان را به IPv4 متصل می‌کند.
• AAAA: همان نام را به IPv6 متصل می‌کند.

انتشار AAAA یک قرارداد عمومی است: این نام روی IPv6 باید Route برگشت، Listener، TLS، فایروال و ظرفیت سالم داشته باشد. صرف مشاهده یک IPv6 در پنل هاست کافی نیست. دامنه اصلی، www، API، فایل‌ها، WebSocket، Callback و Health endpoint را جدا موجودی کنید؛ آمادگی یکی، آمادگی همه نیست.

برای طراحی TTL، DNSSEC، رکوردهای Authoritative و مهاجرت Provider، راهنمای مدیریت DNS دامنه را کنار این Runbook استفاده کنید.

Dual‑Stack، IPv6‑Only، NAT64 و DNS64 چه هستند؟

Dual‑Stack؛ نقطه شروع رایج سایت موجود

Edge یا سرور هر دو خانواده را ارائه می‌کند. سازگاری Client بیشتر است، اما دو مسیر Failure و دو سطح کنترل می‌سازد. «هر دو روشن‌اند» پایان پروژه نیست؛ باید Policy، Telemetry و SLO هر دو هم‌سطح باشد.

IPv6‑Only؛ انتخاب معماری، نه میانبر

شبکه یا Workload فقط IPv6 دارد. این مدل برای محیط جدید قابل بررسی است، اما APIهای IPv4‑only، Registry، مخزن بسته، درگاه، سرویس پیامک، Webhook و ابزار مدیریت باید آزمون شوند. IP literalهای هاردکدشده معمولاً زودتر از DNS نامناسب آشکار می‌شوند.

NAT64 و DNS64؛ پل دسترسی به IPv4

در شبکه IPv6‑Only، NAT64 می‌تواند ترافیک مقصد IPv4 را ترجمه کند و DNS64 برای نام دارای A، پاسخ AAAA ترکیبی بسازد. این سازوکار راه گذار است، نه شاهد سازگاری کامل اپلیکیشن؛ DNSSEC، IP literal و بعضی پروتکل‌ها نیازمند توجه جدا هستند.

SLAAC، DHCPv6 و Router Advertisement چه نقشی دارند؟

در IPv6، Host معمولاً Router و Prefix را از پیام‌های Router Advertisement می‌شناسد. SLAAC می‌تواند با اطلاعات Prefix آدرس بسازد؛ DHCPv6 نیز بسته به طراحی برای اطلاعات یا تخصیص Statefull به کار می‌رود. این اجزا را هم‌معنی و جایگزین کامل یکدیگر فرض نکنید.

Neighbor Discovery در RFC ۴۸۶۱ کشف Router، Prefix، همسایه و دسترس‌پذیری را تعریف می‌کند و RFC 4862 پیکربندی Stateless را شرح می‌دهد. در دیتاسنتر یا VPC، مستندات Provider مرجع پیکربندی است؛ فعال‌کردن RA یا Forwarding بدون فهم نقش Host/Router می‌تواند Route را تغییر دهد یا ترافیک را قطع کند.

روی شبکه محلی تحت مدیریت خود، RA و Neighbor Discovery بخشی از مدل تهدید Layer ۲ هستند. کنترل‌هایی مانند RA Guard فقط پس از بررسی سازگاری تجهیزات و سناریوی واقعی پیاده شوند؛ Rule کور ممکن است همان پیام‌های لازم را حذف کند.

IPv6 literal در URL، تنظیمات و دیتابیس چه دام‌هایی دارد؟

نام دامنه را به IP literal ترجیح دهید. اگر برای عیب‌یابی ناچارید IPv6 و Port را در URI بنویسید، آدرس داخل کروشه قرار می‌گیرد: https://[2001:db8::10]:8443/. این تفکیک مانع اشتباه Colonهای آدرس با جداکننده Port می‌شود؛ نحو URI در RFC 3986 تعریف شده است.

Regex دست‌ساز برای «اعتبارسنجی کامل IPv6» معمولاً همه نمایش‌ها، IPv4‑mapped address یا Zone ID را درست پوشش نمی‌دهد. از Parser استاندارد زبان/Framework استفاده کنید و سپس نیاز محصول—Host، Prefix یا Endpoint—را جدا اعتبارسنجی کنید.

چک‌لیست آمادگی هاست، اپلیکیشن و وابستگی‌ها

• Provider، Prefix/Address، Gateway، Route و رفتار پس از Snapshot یا مهاجرت را مستند کرده است.
• سیستم‌عامل، Hypervisor، VPC، Load Balancer، Container network و Control panel از IPv6 پشتیبانی می‌کنند.
• وب‌سرور، Runtime، دیتابیس، Cache، Queue و Agentهای Backup/Monitoring با IPv6 آزمون شده‌اند.
• Security Group، Host firewall، WAF، ACL خروجی و دسترسی مدیریت قواعد IPv6 دارند.
• CDN و Reverse Proxy مسیر Client→Edge و Edge→Origin را جدا توضیح می‌دهند.
• Allowlistهای درگاه، پیامک، شریک، Webhook و CI/CD به IP قدیمی وابسته نیستند.
• Application، Analytics و SIEM آدرس و Prefix را بدون Truncate یا افزایش خطر حریم خصوصی پردازش می‌کنند.
• Owner، Window تغییر، Guardrail، Rollback و Escalation ارائه‌دهنده مشخص‌اند.

اگر انتخاب زیرساخت هنوز قطعی نیست، راهنمای انتخاب هاست بر پایه Workload و SLO کمک می‌کند قابلیت IPv6 را کنار Capacity، Backup، Support و Exit بسنجید؛ نه به‌عنوان یک تیک تبلیغاتی.

مراحل راه‌اندازی IPv6 برای وب‌سایت

۱. Service map و Dependency inventory بسازید

Hostnameها، Edge، Origin، API، Admin، WebSocket، ایمیل، Payment، DNS، Monitoring و Vendorها را در یک جدول بنویسید. برای هر مورد Owner، خانواده فعلی، مقصد مطلوب و Rollback را ثبت کنید. جست‌وجوی IP literal را در کد، Secret، Pipeline و مستندات فراموش نکنید.

۲. IPv6 را در شبکه و سیستم‌عامل فعال کنید

تنظیم را عیناً از Provider بگیرید. Address، Prefix length، Default route، Neighbor state و Source address انتخاب‌شده را بررسی کنید. ابتدا Outbound و سپس Inbound را با ابزارهای مجاز بسنجید. از تغییر هم‌زمان چند لایه بدون Evidence خودداری کنید.

۳. Listener و زنجیره TLS را آماده کنید

وب‌سرور یا Load Balancer باید روی IPv6 و Portهای لازم Listen کند. رفتار [::] درباره پذیرش IPv4 در همه سیستم‌عامل‌ها یکسان فرض نشود؛ Bind هر خانواده را صریح مشاهده کنید. تست TLS باید با Hostname/SNI انجام شود، نه فقط اتصال خام به IP.

۴. برابری امنیت و Logging را اثبات کنید

Ingress، Egress، SSH/VPN، WAF، Rate limit و Alert را مقایسه کنید. یک Diff ساده از Policyهای IPv4 و IPv6 بسازید، ولی قواعد را کورکورانه Copy نکنید؛ CIDR و نقش Network متفاوت است. راهنمای فایروال و WAF سایت الگوی Policy، Origin protection و Rollback را تکمیل می‌کند.

۵. پیش از DNS عمومی، Endpoint را تست کنید

با ابزار دارای قابلیت Resolve به IP مشخص، Hostname/SNI واقعی را به IPv6 جدید متصل کنید. Status، Header، Redirect، Cookie، Login، Checkout، Upload، Download، API و Health check را با IPv4 مقایسه کنید. «صفحه اصلی باز شد» معیار پذیرش کافی نیست.

۶. AAAA را در Canary کنترل‌شده منتشر کنید

TTL را به‌اندازه یک پنجره برنامه‌ریزی‌شده از قبل کاهش دهید؛ نه چند دقیقه قبل از تغییر. یک Hostname کم‌ریسک، درصد محدود Edge یا دامنه آزمایشی واقعی را انتخاب و Guardrail تعریف کنید. بعد از تثبیت، TTL را به مقدار عملیاتی برگردانید.

۷. Ramp، Observation window و Rollback اجرا کنید

افزایش دامنه را مرحله‌ای انجام دهید: Asset کم‌ریسک، وب عمومی، API و سپس Journey حساس. بین مراحل به‌اندازه‌ای صبر کنید که Peak، چند ISP و چرخه Cache دیده شود. اگر Guardrail رد شد، AAAA را حذف یا مسیر Edge را برگردانید؛ اثر DNS فوراً برای همه Resolverها و Connectionهای باز ناپدید نمی‌شود.

دستورهای پایه برای بررسی DNS و اتصال

نمونه‌ها را فقط در محیط مجاز اجرا و دامنه خود را جایگزین کنید:

dig A example.com
dig AAAA example.com
curl -4 -I https://example.com/
curl -6 -I https://example.com/
curl -6 --resolve example.com:443:[2001:db8::10] -I https://example.com/
ip -6 addr
ip -6 route
ss -lnt

dig پاسخ DNS و curl -4/-6 مسیر هر خانواده را جدا نشان می‌دهند. --resolve برای Pre‑DNS test مفید است چون Hostname و SNI حفظ می‌شوند. شکست curl -6 همیشه خرابی سرور نیست؛ ابتدا مطمئن شوید خود Probe اتصال و Route IPv6 واقعی دارد.

خروجی دستورها Evidence است، نه تشخیص نهایی. DNS سالم با TCP بسته، TCP سالم با TLS معیوب و HTTP ۲۰۰ با محتوای خطا ممکن است هم‌زمان رخ دهند.

ICMPv6، PMTUD و Fragmentation؛ منبع خرابی‌های مبهم

در IPv6، Router میانی Packet را Fragment نمی‌کند. مبدأ باید اندازه مناسب مسیر را رعایت کند و پیام‌های ICMPv6 از جمله Packet Too Big برای Path MTU Discovery اهمیت دارند. اگر فایروال همه ICMPv6 را ببندد، ممکن است درخواست کوچک کار کند اما پاسخ بزرگ، Upload یا TLS در بخشی از مسیر گیر کند.

RFC ۴۸۹۰ درباره فیلتر ICMPv6 بین پیام‌های لازم، قابل‌مدیریت و پرریسک تمایز می‌گذارد. راه درست «Allow all» یا «Deny all» نیست؛ Rule set باید نوع پیام، جهت، Interface و نقش Host/Router را بشناسد.

فایروال، WAF و Rate limit در IPv6

چهار کنترل را جدا ببینید: Network ACL/Security Group، Host firewall، Edge/WAF و کنترل داخل اپلیکیشن. هر کدام Owner و Scope متفاوت دارد. Ruleهای IPv4 ممکن است به جدول یا Address family دیگری تعلق داشته باشند و خودکار روی IPv6 اعمال نشوند.

Rate limit صرفاً بر یک IP Client در IPv6 همیشه مقاوم نیست؛ کاربر یا مهاجم ممکن است چند آدرس از یک Prefix داشته باشد. بسته به مدل تهدید، Signalهای Account، Session، Device، ASN، رفتار و Prefix را ترکیب کنید. Prefix aggregation را بدون تحلیل شبکه و False positive اعمال نکنید؛ کاربران سازمانی، Carrier و Privacy address می‌توانند الگوهای متفاوتی بسازند.

در لاگ، آدرس کامل برای Incident ممکن است لازم باشد، اما نگهداری بی‌حد آن ریسک حریم خصوصی دارد. Purpose، Retention، دسترسی و Masking را تعریف کنید. اگر Reverse Proxy دارید، فقط Header واقعی IP از Proxyهای مورداعتماد را بپذیرید؛ اعتماد عمومی به X-Forwarded-For امکان جعل هویت منبع می‌سازد.

نقش CDN، Load Balancer و Origin در مهاجرت IPv6

CDN می‌تواند Client را روی IPv6 بپذیرد و به Origin با IPv4 متصل شود. در نتیجه «دامنه IPv6 دارد» لزوماً یعنی کل زنجیره IPv6 نیست. چهار Segment را جدا ثبت کنید: User→DNS، User→Edge، Edge→Origin و Origin→Dependency.

برای PoC، امنیت Origin و ارزیابی مسیرهای کاربران ایران، راهنمای انتخاب و راه‌اندازی CDN برای سایت ایرانی را ببینید.

مانیتورینگ درست IPv4 و IPv6

یک Check عمومی که سیستم‌عامل خانواده سریع‌تر را انتخاب می‌کند کافی نیست. Probeهای اجباری IPv4 و IPv6 بسازید و این SLIها را جدا نگه دارید:

• DNS answer و زمان Resolution برای A و AAAA؛
• TCP connect، TLS handshake و اعتبار Certificate؛
• HTTP status، TTFB و Assertion محتوایی؛
• Success rate و p50/p95/p99؛
• تفکیک Region، ISP/ASN و Mobile/Fixed در حد داده معتبر؛
• Dependency error و مسیر Edge→Origin؛
• نرخ Fallback و تفاوت IPv4/IPv6 در RUM، اگر ابزار قابل اعتماد دارید.

راهنمای مانیتورینگ آپتایم برای Probe و Alert بیرونی مناسب است؛ برای پیوند Log، Metric و Trace و کنترل Cardinality آدرس‌ها نیز راهنمای Observability سایت را استفاده کنید.

ماتریس آزمون IPv6 برای کاربران ایران

در ایران نمی‌توان از یک تست دیتاسنتر یا لپ‌تاپ نتیجه کشوری گرفت. دسترسی IPv6، Route و کیفیت آن میان اپراتور موبایل، اینترنت ثابت، سازمان، VPN و زمان‌های مختلف یکسان نیست. عدد Adoption خارجی نیز جای داده کاربران واقعی شما را نمی‌گیرد.

مثلاً فروشگاهی با کاربران موبایل نباید فقط بازشدن صفحه اصلی از سرور تهران را بسنجد. افزودن کالا، Login، رفتن به درگاه، بازگشت Callback، ثبت سفارش و دانلود رسید باید روی هر دو خانواده تست شود. اگر درگاه یا پیامک فقط IPv4 است، Dual‑Stack بودن Frontend الزاماً مشکل نیست؛ وابستگی خروجی باید Route و DNS سالم داشته باشد.

قرارداد Rollout و Rollback بدون اختلال

Rollback با حذف AAAA کامل نمی‌شود: Resolver cache، TTL، Browser connection، CDN config و Sessionهای باز عمر مستقل دارند. زمان «بازگشت مشاهده‌شده» را در Drill اندازه بگیرید. اگر تغییر هم‌زمان Hosting یا Load Balancer دارید، Snapshot و Backup جای Runbook بازیابی نیست؛ راهنمای بازیابی فاجعه و Backup سایت برای RPO/RTO و Restore drill مکمل است.

هزینه و ارزش تجاری IPv6 را چگونه بسنجیم؟

هزینه فقط خرید آدرس یا گزینه پنل نیست. زمان مهندسی، ارتقای Firewall/WAF، اصلاح Schema و Regex، Log volume، Probe جدید، آموزش On‑call و ریسک Change را حساب کنید. در مقابل، پوشش کاربران IPv6، کاهش وابستگی به ترجمه در بخش‌هایی از مسیر، آمادگی Vendor و امکان طراحی IPv6‑only داخلی می‌تواند ارزش ایجاد کند.

یک Business case ساده شامل Baseline نرخ موفقیت، سهم ترافیک قابل مشاهده IPv6، Cost تغییر، Incident exposure و ارزش کاهش ناسازگاری است. اگر هیچ Telemetry ندارید، ابتدا Edge IPv6 یا Pilot محدود را برای یادگیری اجرا کنید. شعار «آینده اینترنت» به‌تنهایی اولویت Roadmap را تعیین نمی‌کند.

IPv6 چه اثری بر سئو دارد؟

IPv6 را ترفند رتبه‌گیری نبینید. ارزش آن زیرساختی است. AAAA خراب می‌تواند Timeout، شکست TLS و دسترس‌پذیری ناپایدار بسازد و همین اختلال بر کاربر و خزش اثر منفی بگذارد. مسیر سالم و پایش‌شده مانع ایجاد نمی‌کند، اما صرف فعال‌بودن IPv6 وعده رتبه بالاتر نیست.

URL، Canonical، Redirect، Sitemap و محتوای صفحه نباید به‌علت خانواده IP تغییر کنند. دامنه واحد باید همان نسخه Canonical را ارائه دهد. IP literal را در لینک داخلی، Canonical یا Sitemap نگذارید و مطمئن شوید Bot/WAF روی IPv6 Rule متفاوت و ناخواسته ندارد.

اشتباه‌های رایج مهاجرت IPv6

• انتشار AAAA به‌عنوان تست: DNS عمومی آخرین Gate نیست؛ قبل از آن Pre‑DNS test لازم است.
• تست فقط صفحه اصلی: API، Asset، Login، Checkout، Webhook و Admin Failure mode مستقل دارند.
• فرض امنیت خودکار: IPv6 نه HTTPS را فعال می‌کند و نه Firewall را می‌سازد.
• Copy ناقص Ruleها: پورت بسته IPv4 ممکن است روی IPv6 باز باشد یا برعکس.
• مسدودکردن کامل ICMPv6: Neighbor Discovery و PMTUD را مختل می‌کند.
• اعتماد به Happy Eyeballs: Fallback، پیکربندی خراب را سالم نمی‌کند.
• ذخیره در فیلد ۱۵ نویسه‌ای: داده بریده و تحلیل یا کنترل امنیتی معیوب می‌شود.
• Rate limit فقط بر یک IP: Prefix و Signalهای هویتی/رفتاری نادیده می‌مانند.
• تست از یک ISP: تفاوت Route و Peering کاربران واقعی پنهان می‌شود.
• Rollback کاغذی: TTL، Cache و Connection باعث بازگشت غیرآنی می‌شوند.

برنامه اجرایی ۳۰روزه برای فعال‌سازی IPv6

این زمان‌بندی نمونه است؛ فروشگاه پرتراکنش یا سامانه حساس ممکن است Observation window طولانی‌تر بخواهد. Scope را با Criticality تعیین کنید، نه با تقویم ثابت.

چک‌لیست نهایی پیش از انتشار AAAA

• Hostname و همه Journeyهای آن Owner دارند.
• Address، Prefix، Route و Listener با Evidence ثبت شده‌اند.
• TLS/SNI، Redirect و Content با IPv4 همسان و سالم‌اند.
• Firewall، WAF، Rate limit و Origin protection برای IPv6 آزمون شده‌اند.
• ICMPv6 لازم عبور می‌کند و Payload بزرگ تست شده است.
• IP در Database، Log، SIEM، Allowlist و UI درست پردازش می‌شود.
• Probe اجباری IPv4/IPv6 روی چند شبکه وجود دارد.
• Baseline، SLO، Guardrail، Owner و Escalation روشن است.
• TTL از قبل تنظیم و Rollback با Cache/Connection تمرین شده است.
• Review پس از تغییر و زمان افزایش TTL برنامه دارد.

سؤالات متداول درباره IPv6

آیا برای فعال‌سازی IPv6 باید IPv4 را حذف کنم؟

خیر. برای بیشتر سایت‌های موجود، Dual‑Stack مسیر عملی‌تری است. IPv4 را تا زمانی که کاربران و وابستگی‌ها نیاز دارند نگه دارید و هر مسیر را مستقل پایش کنید.

آیا فقط افزودن رکورد AAAA کافی است؟

خیر. AAAA باید به مسیری اشاره کند که Route، Listener، TLS، Firewall، Application و Monitoring آن روی IPv6 آماده است. ابتدا Pre‑DNS test و سپس Canary انجام دهید.

آیا IPv6 سایت را سریع‌تر یا امن‌تر می‌کند؟

نه به‌طور تضمینی. سرعت به Route و Peering و امنیت به کنترل‌های عملیاتی وابسته است. نتیجه را با SLIهای مستقل IPv4/IPv6 و آزمون امنیتی بسنجید.

چرا curl روی IPv6 کار می‌کند اما بعضی کاربران خطا دارند؟

Probe شما فقط یک شبکه و مسیر را نشان می‌دهد. تفاوت ISP، DNS cache، MTU، CDN PoP، TLS یا Journey خاص می‌تواند علت باشد. Probe چندشبکه‌ای و تفکیک مرحله DNS/TCP/TLS/HTTP لازم است.

اگر بعد از انتشار AAAA خطا بالا رفت چه کنیم؟

Guardrail را اجرا کنید، Scope را یک مرحله برگردانید یا AAAA را موقتاً حذف کنید و هم‌زمان Evidence نگه دارید. Cache DNS و Connectionهای باز باعث می‌شوند بازگشت برای همه کاربران آنی نباشد.

جمع‌بندی: IPv6 یک پروژه دسترس‌پذیری است

مهاجرت موفق IPv6 یک تغییر DNS یک‌خطی نیست. Service map بسازید، شبکه و اپلیکیشن را آماده کنید، امنیت و مشاهده‌پذیری را هم‌سطح IPv4 برسانید، پیش از انتشار عمومی تست کنید و AAAA را با Canary، Guardrail و Rollback مرحله‌ای گسترش دهید. برای سایت ایرانی، تصمیم نهایی باید بر Evidence چند ISP و Journey واقعی استوار باشد.

اگر برای ارزیابی آمادگی هاست، DNS، CDN، فایروال یا طراحی Rollout بدون اختلال کمک می‌خواهید، از فرم درخواست مشاوره مایندیو مشخصات دامنه، Providerها و مسیرهای بحرانی را بفرستید.

مطالب مرتبط

• انتخاب هاست بر پایه Workload، SLO و Pilot
• مدیریت DNS، DNSSEC، TTL و مهاجرت
• انتخاب و راه‌اندازی CDN برای سایت ایرانی
• طراحی و تنظیم فایروال و WAF سایت
• مانیتورینگ آپتایم با Probe مستقل
• Observability با Metric، Log و Trace
• بازیابی فاجعه، Backup و Runbook