הגדרה
IP מהדורה 6 (IPv6) היא גירסה חדשה של פרוטוקול האינטרנט, שנועדה לרשת את הגירסה הנוכחית (IPv4).
המעבר בין רשת האינטרנט IPv4 של היום לבין רשת עתידית שתתבסס על IPv6 יהיה תהליך ארוך שבמהלכו יתתקימנה שתי הגירסאות במקביל. ארגון IETF הקים את קבוצת העבודה NGTrans כדי לסייע במעבר ל-IPv6 ולהציע פתרונות טכניים להשגתו.
רקע
המפרט הטכני של IPv6 מציג שינויים גדולים. לא רק שאורך כתובת ה-IP הוגדל ל-128 ביט, אלא שגם מבנה הכותרות (header format) בפרוטוקול ואופן העיבוד של המידע שבכותרות עברו שינויים. המעבר מ-IPv4 ל-IPv6 אינו פשוט ויש צורך לתקנן מנגנונים שיאפשרו דו-קיום ומעבר חופשי בין שתי הגירסאות.
מאות מיליוני אנשים מחוברים כיום לאינטרנט ומספר דומה של מחשבים מארחים והתקנים משתמשים בפרוטוקול IP. קביעת יום מוסכם ("D-Day") למעבר מגירסה 4 לגירסה 6 בנוסח המודל של שנת 2000 (Y2K) אינה מעשית. מעבר לגירסה 6 בתוך תקופה כה קצרה יחייב הגדרה מחדש של תוכנית הקצאת כתובות (addressing plan) בהיקף כלל עולמי בגירסה 6, התקנת פרוטוקול IPv6 על כל נתב ומחשב ושינוי כל היישומים הקיימים כך שיפעלו על IPv6. הדבר יגרום להוצאות כבדות ושיבושים בלתי-סבירים בשירות, וכן נזקים חמורים ליישומים קריטיים מבוזרים. גישה כזו תהיה גם חסרת-תכלית, שכן יישומים פעילים רבים אינם מחייבים מיידית את הכנסת השיפורים הגלומים ב-IPv6 או שלא תוכננו להפיק תועלת מן הפונקציונליות הנוספת שמאפשרת הגירסה החדשה.
אין כלל אחיד שניתן להחיל על תהליך המעבר מ-IPv4 ל-IPv6. במקרים מסויימים, מעבר ישיר ל-IPv6 יהיה התשובה. לדוגמה, אפשר לקדם את IPv6 באמצעות החלטה פוליטית להגדיל את מספר כתובות IP כדי לשמור על צמיחתה הכלכלית של מדינה כלשהי. דוגמה נוספת היא פריסה רחבה של ארכיטקטורת IP חדשה (כגון רשתות תקשורת ניידת או ביתית) לצורך אספקת יישומיםושירותים חדשניים.
תוכניות מעבר אחרות יאפשרו הפעלה משותפת הדרגתית של שתי הגירסאות לאורך תהליך המעבר. במקרים אלה יעדיפו ISPs וחברות להגן על השקעותיהם הכבדות בפריסת רשתות IPv4 קיימות.
מספר מחקרים צופים כי תקופת המעבר תימשך מעתה ועד השנים 2030-2040. עד אז, אמורות רשתות IPv4 להיעלם לחלוטין.
סוגיות טכניות
קבוצת העבודה NGTrans הגדירה שלוש טכניקות מעבר עיקריות. הטכניקה הראשונה היא הרשת הכפולה (dual-stack network). גישה זו מחייבת מימוש של שני הפרוטוקולים גם יחד, IPv4 ו-IPv6, על שרתים ונתבים. הדבר מאפשר לרשתות לתמוך בשירותים וביישומים בשני הפרוטוקולים בתקופת המעבר, שבמהלכה יופיעו שירותי IPv6 ותגדל זמינותם של יישומים ל-IPv6. בשלב זה, הגישה הכפולה היא מנגנון יסודי להכנסת IPv6 לשימוש בארכיטקטורות IPv4 קיימות, והיא תישאר בשימוש רב בעתיד הקרוב. חסרונה הוא בכך שלכל מחשב ברשת הדו-שכבתית צריכה להיות כתובת IPv4. עובדה זו מטרידה, שהרי IPv6 פותחה בדיוק בגלל מיעוט הכתובות הזמינות ב-IPv4.
הטכניקה השניה מבוססת על מִנהוּר (tunneling). מִנהוּר מאפשר חיבור בין "ענני" IP. לדוגמה, אפשר לקשר בין רשתות IPv6 נפרדות דרך שירות IPv4 רגיל (native) באמצעות מנהרה. מנות מידע (packets) של IPv6 עוברות "אריזה" (encapsulation) בנתב גבול (border router) לפני העברתן ברשת IPv4, ואחר-כך הן עוברות "פתיחה" (decapsulation) בנקודת הגבול של רשת IPv6 המקבלת. המנהרות יכולות להיות מוגדרות בתצורה סטטית או דינמית, או באופן שקוף (implicit) (6to4, 6over4). שיטת "מתווך המנהרה" (TB – Tunnel Broker) הוצעה כדי לנהל אוטומטית בקשות מנהור המגיעות מן המשתמשים ולהקל על תהליך הבנייה. פרוטוקול ISATAP – Intra-Site Automatic Tunnel Addressing Protocol, הוא טכניקה חדשה המונעת צורך בהגדרת מנהור באופן ידני. לבסוף, בשלבים מאוחרים יותר של המעבר, ייעשה שימוש במנהור גם כדי לקשר את ענני IPv4 הנותרים באמצעות תשתית IPv6.
הטכניקה האחרונה משתמשת במנגנון תרגום.
ALG's
Application- Level Gateways
SIIT
Stateless IP/ICMP Translation
NAT-PT
Network Address Translation – Protocol Translation
DSTM
Dual Stack Transition Mechanism
התרגום נחוץ כאשר מחשב המממש רק את IPv6 צריך להתקשר עם מחשב IPv4. לכל הפחות, יש צורך לתרגם את הכותרת החיצונית, אבל ברור שהתרגום יהיה מורכב יותר אם היישום מטפל בכתובות IP בתוכו; למעשה, תרגום כזה "יורש" את מרבית הבעיות האופייניות למתרגמי הכתובות ברשת IPv4. גישורים ברמת היישום (ALG's ), נחוצים כדי לתרגם כתובות IP הכלולות במידע, לחשב מחדש סכומי בדיקה (checksums), וכדומה. SIIT ו-NAT-PT, הן טכניקות התרגום הרלבנטיות. תערובת של שיטת התרגום והמודל הכפול, הידועה בכינוי DSTM הוגדרה כדי לענות למקרה של חוסר בכתובות IPv4. בדומה לטכניקות המנהור, אפשר לממש את התרגום בנתבי גבול ובמחשבים.
מערך מורכב זה של טכניקות דו-קיום ומעבר מאפשר "ערבוב ושילוב" בדרכים רבות.
השלכות
המעבר אינו תמיד הפתרון – חשוב לזכור כי המעבר אינו הפתרון לכל הבעיות. יישומים חדשניים מסויימים מחייבים IPv6 לצורך פריסה נרחבת. פריסת מנגנוני מעבר בהיקף נרחב עשויה להוביל גם לסוגיות של יכולת גידול (scalability), העלולות לפגוע קשות בביצועי IPv6 בהשוואה לפתרון מקומי.
דו-קיום בין שתי הגירסאות – במקרים שבהם חייב להיות דו-קיום בין שתי הגירסאות, שמירת תהליך המעבר מ-IPv4 ל-IPv6 תחת שליטה היא חיונית, כדי למנוע פריסה של שתי תשתיות אינטרנט מקבילות. יישומי IPv6 ייהנו מן ההשקעות הכבדות שכבר בוצעו כדי לפרוס רשתות IPv4 קיימות.
המשכיות השירות – המעבר מ-IPv4 ל-IPv6 אינו רק שאלה של כתובות או ניתוב. שירותי IPv4 מתקדמים, הזמינים כיום או המצויים בפיתוח, כגון IP QoS, IP Security, וטלפוניה באמצעות IP, מחייבים המשך שירות רצוף בלי קשר לסוג תשתית ה-IP.
פתרונות מעבר – מנגנוני המעבר שהוצעו ע"י קבוצת העבודה NGTrans מציעים מספר כלים חיוניים לבניית אסטרטגיות מעבר. בחירת המנגנונים הנוחים ביותר, וההחלטה היכן למקם אותם וכיצד לפרוס אותם אינה משימה פשוטה. על מנת להקל על המעבר יידרשו תוכניות מעבר שיגדירו המשתמשים בהתבסס על קווים מנחים אלה.
מעבר מבוסס שרתי-קצה – NGTrans התרכזה בטכניקות מעבר ברמת הרשת, ובכללן תרגום. גישה נוספת, משלימה, היא להשתמש בשרתי קצה (edge servers) כפולי פרוטוקול בגבול בין מערכות IPv4 ל-IPv6, כ"מיופי כוח" (Proxies) ברמת היישום, אשר יבטלו את הצורך בתרגום ברמת הרשת.
עמדת ISOC
הנחלתו המוצלחת של IPv6, תחילה באזורים ובתחומי יישום ספציפיים, ומאוחר יותר בשדרת הרשת העולמית, היא אחת הדרישות האסטרטגיות המרכזיות ביותר להמשך צמיחת האינטרנט. ISOC תמשיך לתמוך בעבודת התִקנוּן הדרושה, תתמוך בפעילויות חינוך והכשרה, ותעקוב אחר כל סוגיה במדיניות הציבורית שיש לה נגיעה לפריסת IPv6.
