IPv4 در مسیر تکه‌تکه می‌کند؛ IPv6 به جای آن پیام بسته بیش از حد بزرگ می‌فرستد
تنها مسیریاب‌های IPv4 می‌توانند بسته بیش از حد بزرگ را تکه‌تکه کنند. IPv6 انتظار دارد فرستنده به پیام بسته بیش از حد بزرگ واکنش نشان دهد، که تونل یا قاعده ICMP فیلترشده می‌تواند آن را بشکند.
خطاهای IPv6 بسیار بیشتر به پروتکل نسبت داده می‌شوند تا به اندازه بسته‌ای که آن‌ها را ایجاد کرده است. دو خانواده واقعاً به شکل متفاوتی با بسته بیش از حد بزرگ برخورد می‌کنند و تونل همان چیزی است که این تفاوت را مهم می‌کند. مسیریاب‌های IPv4 می‌توانند بسته را وقتی قواعد اجازه می‌دهند تکه‌تکه کنند، در حالی که مسیریاب‌های IPv6 اصلاً نباید در مسیر تکه‌تکه کنند. IPv6 به جای آن به فرستنده می‌گوید و انتظار می‌رود فرستنده واکنش نشان دهد. هر چیزی که بعداً اشتباه پیش برود از این ناشی می‌شود که آیا آن پیام می‌رسد یا نه.
هر خانواده چه می‌کند
جدول همان سازوکار در چهار سطر است و یک سطر بیشتر سرگردانی را توضیح می‌دهد.
| Behaviour | IPv4 | IPv6 |
|---|---|---|
| Router fragments an oversized packet | Allowed while DF is clear | Never |
| Signal returned to the sender | ICMP Fragmentation Needed | ICMPv6 Packet Too Big |
| Size that must always work | 68 bytes | 1280 bytes |
| Fragmentation possible | Routers or source | Source only |
IPv6 هیچ تکه‌تکه‌سازی در مسیر و هیچ پرچم DF برای پاک کردن ندارد، پس وقتی بسته بیش از حد بزرگ است چیزی برای عقب‌نشینی وجود ندارد. باید به فرستنده گفته شود و فرستنده باید آن را باور کند.
تونل مسیر را بی‌صدا تنگ می‌کند
یک VPN پیش از خروج بسته از میزبان، سرآیندهای بیرونی و در حالت رمزنگاری‌شده داده‌های یکپارچگی هم اضافه می‌کند. بسته درونی می‌تواند در MTU واسطه‌ای که می‌بیند جا شود، در حالی که بسته بیرونی از حد پیوند بعدی فراتر می‌رود و همین است که این مشکل نخست در تونل ظاهر می‌شود. عمداً MTU واسط تونل را کاهش دهید یا TCP MSS را در مسیر مهار کنید و بنویسید کدام عدد را برگزیدید و چرا.
سرباری ESP به حالت و الگوریتم‌ها بستگی دارد، پس MTU درست تونل یک محاسبه است و نه یک عرف. هر چه برگزینید باید جای کافی برای یک بسته IPv6 درونی کامل 1280 بایتی باقی بگذارد، زیرا هر پیوند IPv6 موظف است این مقدار را حمل کند. تونلی که نمی‌تواند 1280 بایت IPv6 را حمل کند مشکل تنظیم نیست؛ مسیری شکسته برای آن خانواده است. همین محدودیت است که وقتی مقدار MTU از استقراری تنها بر پایه IPv4 کپی می‌شود از میان می‌رود.
چرا نشانه یک توقف است
شکست یک خطای تمیز نیست و به همین دلیل بد تشخیص داده می‌شود. دست‌دادن TCP کامل می‌شود، پاسخ‌های کوچک می‌رسند و اتصال به محض آغاز یک پاسخ بزرگ یا یک بارگذاری انبوه متوقف می‌شود، زیرا آن‌ها نخستین بسته‌های به اندازه کافی بزرگ برای دور انداختن هستند. SSH متصل می‌شود و سپس روی نخستین خروجی بزرگ متوقف می‌شود و سرآیند یک صفحه بار می‌شود در حالی که بدنه هرگز تمام نمی‌شود.
اگر پیام‌های ICMPv6 درباره بسته بیش از حد بزرگ فیلتر شوند، فرستنده هرگز باخبر نمی‌شود و همان اندازه را بارها تکرار می‌کند. این یک سیاه‌چاله است و نه یک مسیر کند، و نشانه‌اش یک مرز اندازه تکرارشدنی است و نه افت تصادفی. مجاز گذاشتن ترافیک کنترلی مربوطه بخشی از استقرار کارآمد IPv6 است، نه یک لطف.
پیام‌هایی را که مسیر خودتان به آن‌ها وابسته است خاموش نکنید و سپس نتیجه را نقص IPv6 بنامید. همین استدلال برای پیام‌های Fragmentation Needed در IPv4 هم صادق است، که نزد نویسندگان دیوار آتش به همان اندازه نامحبوب و به همان اندازه ضروری‌اند.
مرز را اندازه بگیرید و سپس لایه را درست کنید
به جای حدس زدن بررسی کنید: از پرچم don't-fragment در IPv4 و اندازه‌های ثابت بار در IPv6 استفاده کنید و ثبت کنید پاسخ‌ها کجا متوقف می‌شوند. ping -M do -s 1472 و ping -6 -s 1400 برای تعیین شکل مشکل کافی‌اند و tracepath MTU مسیر کشف‌شده را در طول راه گزارش می‌کند.
سپس لایه‌ای را درست کنید که صاحب آن عدد است: MTU واسط تونل، مهار MSS برای TCP، یا خود مسیر. RFC 8200 مرجع قاعده IPv6 است و خواندنش کوتاه‌تر از حادثه‌ای است که جلوگیری می‌کند.
خانواده‌ای را آزمایش کنید که برنامه واقعاً به کار می‌برد، زیرا یک نام دوپشته می‌تواند در یک خانواده پاسخ دهد و در دیگری نه، و برنامه می‌تواند پس از تغییر شبکه جابه‌جا شود. نشانی‌ای را که آزمایش کردید ثبت کنید، زیرا نتیجه در برابر رکورد A چیزی درباره رکورد AAAA نمی‌گوید.
با مرز اندازه مانند مدرک برخورد کنید
مرز اندازه تکرارشدنی یکی از معدود خرابی‌های شبکه است که دقیقاً بازتولید می‌شود، با همان تعداد بایت، از همان منبع، هر بار. این آن را هدیه می‌کند و نه معما، و همچنین یعنی می‌توان اصلاح را تأیید کرد و نه آرزو.
MTU کشف‌شده، MTU تونلی که پیکربندی کردید و آزمونی که تفاوت را ثابت کرد در تیکت بنویسید. فرد بعدی همان حساب را روی پیوندی دیگر خواهد دید.