מה IPv6CP מנהל ומה עדיין דורש קידומת
כתובת link-local בממשק ה-PPP היא שלב הגדרה, לא גישה ל-IPv6. הפרידו בין חילופי המזהים לבין קידומות, מסלולים ושילוב הלקוח.
IPv6 עולה על ממשק ה-PPP, מופיעה כתובת link-local, והשינוי מוכרז כגמור. ואז שום דבר לא מנותב, אין כתובת גלובלית, ובדיקה אל יעד ציבורי נכשלת בעוד הממשק עדיין נראה מוגדר. הקישור עלה; הרשת מעולם לא. עברו על ארבע הבדיקות שלמטה לפי הסדר ועצרו בזו שמסבירה את הפער.
מה כתובת link-local באמת מוכיחה
IPv6CP מעלה את IPv6 על קישור ה-PPP ומנהל משא ומתן על מזהה ממשק לכל צד. המזהה הזה יוצר כתובת link-local, שמספיקה כדי לדבר עם העמית דרך הקישור ואינה מספיקה כדי להגיע לשום דבר אחר. הכתובת מוכיחה שהקישור מוכן ל-IPv6, והיא אינה מוכיחה דבר על הרשת שמאחורי העמית. לקרוא בה כתובת גישה זו הטעות שבה מתחילות רוב החקירות האלה.
ארבע השאלות שלמטה מפרידות בין מה ששכבת הקישור קובעת לבין מה שהשירות חייב לספק. ענו עליהן לפי הסדר, כי על שאלה מאוחרת אי אפשר לענות כל עוד קודמתה פתוחה.
| Question | Answered by | What it does not settle |
|---|---|---|
| Is IPv6 up on the link? | IPv6CP: interface identifiers, then link-local addresses | Any address reachable beyond the peer |
| Where does a global prefix come from? | Router advertisement, delegated prefix, DHCPv6 or static configuration | IPv6CP carries no prefix of its own |
| Who owns the routes? | The client's tunnel configuration and the server's return path | A link-local address implies no route at all |
| How does this client get configured? | Explicit tunnel settings or router advertisements, depending on the client | The standard does not choose for the implementation |
מאין חייבת הקידומת לבוא
כתובת גלובלית זקוקה לקידומת ממקום כלשהו: הודעת נתב, קידומת מואצלת, DHCPv6 או הגדרה סטטית. IPv6CP אינו נושא קידומת כזו, וכל המתנה על הקישור לא תייצר אחת. RFC 5072 ממקם את IPv6CP כשלב ההגדרה שרץ לפני שפרוטוקולי IPv6 אחרים פועלים על הקישור, וזה כל היקפו: להכין את הקישור, לא למספר את הרשת. ספקו את הקידומת והממשק יתחיל לשאת תעבורה במקום רק להתקיים.
הודעות נתב הן התשובה הנפוצה ברשת מקומית והפחות אמינה במנהרת נקודה לנקודה, משום שהלקוח חייב גם לשלוח בקשות וגם לקבל את התשובה. יש לקוחות מנהרה שאינם עושים אף אחד מהם. בדקו מה הלקוח מוכן לקבל לפני שתחליטו שהשרת צריך לשלוח אותו.
אותה קידומת חייבת להיות נגישה מהקצה השני. לקוח שמחזיק כתובת גלובלית אך אין לו נתיב חזרה מוגדר, לא מחובר.
מסלולים הם הבטחה נפרדת
גם עם כתובת, הלקוח צריך לדעת אילו יעדים שייכים למנהרה, והשרת זקוק לנתיב חזרה לאותם יעדים. אלה שתי החלטות שמתקבלות בשני מקומות. מנהרה שנושאת את כל תעבורת IPv6 זקוקה לנתיב ברירת מחדל בלקוח ולנתיב חזרה בשרת; מנהרה מפוצלת זקוקה לכך ששני הצדדים יסכימו על אותה רשימת קידומות. כשהם אינם מסכימים, התעבורה יוצאת ולא חוזרת לעולם.
רשמו את הרשימה לפני שתגדירו משהו. אם התוכנית אומרת שרק קידומת החברה עוברת במנהרה, ללקוח לא צריך להיות נתיב IPv6 כברירת מחדל, ולשרת לא צריך להכריז על אחד.
שילוב הלקוח קובע את השאר
יש לקוחות מנהרה שמגדירים IPv6 במפורש. Network Extension של Apple, למשל, לוקח כתובת, קידומת וקבוצת מסלולים עבור המנהרה, כך שיישום שמשתמש בו אינו ממתין להודעה בסגנון Ethernet. אחרים מסתמכים על הודעות נתב שמגיעות דרך הקישור. שני המודלים לגיטימיים והם דורשים התנהגות שרת שונה, ולכן בחירה שגויה מייצרת לקוח שממתין לנצח להודעה שאיש אינו שולח. זהו את המודל לפני שתשנו את השרת.
שם ממשק ישן כמו ppp0 אינו מוכיח דבר על המחסנית שרצה היום. לקוח עכשווי עשוי להשתמש ב-API של מנהרת מנות במקום בממשק PPP, וההנחה שהוא מתנהג כמו חיבור היסטורי היא הדרך לשבור תכנון עובד. שאלו על גרסת הלקוח ושיטת האספקה, לא על שם הממשק.
כתבו את התוכנית שהלקוח צריך
תיאור מלא מכסה שלושה דברים: איזו כתובת מחזיק הלקוח, אילו יעדים המנהרה צריכה לשאת, וכיצד הרשת שולחת תשובות חזרה. כתובת link-local אינה עונה על אף אחד מהם, והודעה שהתקבלה עונה רק על חלק מאחד. בדקו כל פריט בנפרד במקום לקבל מחוון ירוק. לאחר מכן רשמו איזה מנגנון סיפק כל תשובה, משום שהרשומה הזו הופכת את דוח ה-IPv6 הבא לבדיקה של שתי דקות.
שמרו את הרשומה עם תיעוד השירות ועדכנו אותה כשהלקוח משתנה. תוכנית שהייתה נכונה ללקוח PPP עשויה להיות שגויה ללקוח מנהרת מנות באותו שירות. ארבע השאלות נשארות זהות; רק התשובות זזות.