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 המנהרה שהגדרתם ואת הבדיקה שהוכיחה את ההבדל. האדם הבא יפגוש את אותה אריתמטיקה בקישור אחר.