מעבר ל IP V6
- פותח הנושא יואב שניר
- פורסם בתאריך
בצילום מסך שלו יש לשוניות
ברור שיש לו v4, לתפוז אין רשומות AAAA (רשומות v6)
הבעיה בעיקר כאשר לאתר או משאב כלשהו אין כתובת v4 כאשר למשתמש אין v6 מכל סוג, למשל לכאן לא תוכל להכנס ללא IPv6
למרות שקיימת אפשרות לספק גישה לאינטרנט v6 בלבד, בד"כ לא מספקים כזה, כי אחרת רק משאבי v6 היו נגישים (או כפי שציינת, mapping כתובות v4 בתוך 6 ואז קישוריות לא פועלת כמו שצריך)
את הבעיה ההפוכה יש ונפוץ, כבר שני עשורים שמושכים את החתול בביצים עם המעבר לתמיכת ipv6 נאטיבית (הקצאת שני כתובות מהספק, כתובת v4 וטווח v6), כך שהמשתמש נאלץ להגדיר גישה למשאבי v6 בעצמו, דרך מנהור 6in4 למשל.
ברור שיש לו v4, לתפוז אין רשומות AAAA (רשומות v6)
הבעיה בעיקר כאשר לאתר או משאב כלשהו אין כתובת v4 כאשר למשתמש אין v6 מכל סוג, למשל לכאן לא תוכל להכנס ללא IPv6
למרות שקיימת אפשרות לספק גישה לאינטרנט v6 בלבד, בד"כ לא מספקים כזה, כי אחרת רק משאבי v6 היו נגישים (או כפי שציינת, mapping כתובות v4 בתוך 6 ואז קישוריות לא פועלת כמו שצריך)
את הבעיה ההפוכה יש ונפוץ, כבר שני עשורים שמושכים את החתול בביצים עם המעבר לתמיכת ipv6 נאטיבית (הקצאת שני כתובות מהספק, כתובת v4 וטווח v6), כך שהמשתמש נאלץ להגדיר גישה למשאבי v6 בעצמו, דרך מנהור 6in4 למשל.
מתוך רשת IPv4 בלבד עם עדיין יש בה צורך, מנגישים גישה
לרשת IPv6 על ידי פתרונות מנהור למניהם כמו 6in4
מתוך רשת שהיא IPv6 בלבד ואינה דואל סטאק, מגדירים כאמור NAT64+DNS64 וגישה למשאבי IPv4 - לפי צורך בלבד - תוך כדי כיתוב כתובות IPv4 בכיתוב המיועד לכך ברשת המיועדת לכך, למשל כתובת של תפוז 31.168.230.10 תהיה אמורה להיות נגישה - כמובן מרשת עם NAT64 פועל כראוי - כ-64:ff9b::1fa8:e60a/96
או (תלוי באימפלמנטציה) כ-::ffff:1fa8:e60a
למעשה אם יש לך ipv6 (כולל כזה שמתקבל ממנהור) אז פינג לכיתוב השני אמור לתת מענה, אבל לא תקבל את תפוז בדפדפן דרך כתובת שכזו (http://[::ffff:1fa8:e60a]) כי סביר להניח ולא הוגדר DNS64 וב-DNS ציבוריים של הספקים, או ב-hosts או בנתב או ב-DNS של ספק כתובת מנהור, לא הוגדרו רשומות AAAA שתפנה לכתובת שכזו (שמעידה שמשאב זה קיים רק ברשת v4 ולכן דורש "תרגום").
הכוונה עמ הזמן להפטר מרשת IPv4 כליל, ובכלל נראה שאפילו לא טרחת לקרא על הנושאים שהזכרתי בהודעה הקודמת וכן את תקני IETF הרלוונטיים
נ.ב. http://gestioip.net/docu/ipv6_address_examples.html
לרשת IPv6 על ידי פתרונות מנהור למניהם כמו 6in4
מתוך רשת שהיא IPv6 בלבד ואינה דואל סטאק, מגדירים כאמור NAT64+DNS64 וגישה למשאבי IPv4 - לפי צורך בלבד - תוך כדי כיתוב כתובות IPv4 בכיתוב המיועד לכך ברשת המיועדת לכך, למשל כתובת של תפוז 31.168.230.10 תהיה אמורה להיות נגישה - כמובן מרשת עם NAT64 פועל כראוי - כ-64:ff9b::1fa8:e60a/96
או (תלוי באימפלמנטציה) כ-::ffff:1fa8:e60a
למעשה אם יש לך ipv6 (כולל כזה שמתקבל ממנהור) אז פינג לכיתוב השני אמור לתת מענה, אבל לא תקבל את תפוז בדפדפן דרך כתובת שכזו (http://[::ffff:1fa8:e60a]) כי סביר להניח ולא הוגדר DNS64 וב-DNS ציבוריים של הספקים, או ב-hosts או בנתב או ב-DNS של ספק כתובת מנהור, לא הוגדרו רשומות AAAA שתפנה לכתובת שכזו (שמעידה שמשאב זה קיים רק ברשת v4 ולכן דורש "תרגום").
הכוונה עמ הזמן להפטר מרשת IPv4 כליל, ובכלל נראה שאפילו לא טרחת לקרא על הנושאים שהזכרתי בהודעה הקודמת וכן את תקני IETF הרלוונטיים
נ.ב. http://gestioip.net/docu/ipv6_address_examples.html
רק כתובת link-local תלויה דרך EUI-64 ב-MAC
שאר הסוגים כולל SLAAC ו-DHCPv6 יוקצו מתוך טווח ה-64/ שלך ואתה רשאי לעשות בטווח הזה מה שאתה רוצה כולל להקצות 64^2 כתובות לכל מכשיר בבית שלך בתנאי שכל 64 הסיביות של מכשירים יהיה תמיכה ב-DHCPv6, אם כן - אתה רשאי להקצות 128/ לכל אחד מ-64^2 הממשקים, אם לא - חייב לשמור כתובות לפעילות SLAAC.
 
רק הכתובת הראשונית תחובר לראש הרשת בנתב, מה אז הנתב יעשה עם הטווח של 64/ אחרונים תלוי בלקוח
שאר הסוגים כולל SLAAC ו-DHCPv6 יוקצו מתוך טווח ה-64/ שלך ואתה רשאי לעשות בטווח הזה מה שאתה רוצה כולל להקצות 64^2 כתובות לכל מכשיר בבית שלך בתנאי שכל 64 הסיביות של מכשירים יהיה תמיכה ב-DHCPv6, אם כן - אתה רשאי להקצות 128/ לכל אחד מ-64^2 הממשקים, אם לא - חייב לשמור כתובות לפעילות SLAAC.
 
רק הכתובת הראשונית תחובר לראש הרשת בנתב, מה אז הנתב יעשה עם הטווח של 64/ אחרונים תלוי בלקוח
תשובה
1. כתובת טווח fe80::/10 וסיומת שתלויה ב-MAC של הלקוח. הגדרה https://tools.ietf.org/html/rfc4291#section-2.5.6 . אין תקשורת לאינטרנט, אבל יש תקשורת באותה הרשת הפנימית - ניתן לתקשר עם לקוח אחר ברשת הפנימית הישירה (link-local) (אשר זמינה בפקודת arp -a אשר בהשוואה ל-ipv4 אמור לקבל את כל מה שרואים מ-broadcast דרך כתובת המסכה). היא תחזיק לעד, למעשה ניתן להתייחס לזה גם ככתובות הקצאה קבועה של DHCPv4 ברשת פנימית rfc1918 וגם כאל כתובות 169.254/16 של IPv4 לקונפיגורציה אוטומטית כאשר אין כתובת טובה יותר כאמור.
2. כתובת שניה, מוקצית SLAAC על ידי הנתב והמערכת:
2.1. כאשר פיצ'ר הפרטיות rfc4941 כבוי, מועתק מאותה הכתובת הפנימית של fe80, אל תוך הטווח הציבורי 64/ שקיבלת מהספק. במקרה זה הוא קבוע, וזמין מהאינטרנט ומזהה אותך לפי MAC ישר
2.2. כאשר הפיצ'ר לעיל פועל (תלוי בהגדרות נתב/מערכת, וזה לא בהכרח דבר נגיש להגדרה על ידי משתמש דרך דף הגדרות נתב או הגדרות לקוח, בדרך כלל זה פועל, אבל יש מכשירים שאצלם זה כבוי ללא אפשרויות קינפוג, ולשינוי מצריך קושחא מתואמת אישית וקינפוג ב-ssh ו/או במקרה של לקוח, חיטוט ב-regedit או קבצי קונפיג לינוקסאים) מורכב מכתובת ספק (הטווח שלך) פלוס גרסה "ערוכה" של כתובת סעיף 2.1 באופן כזה שלא מאפשר זיהוי MAC של הלקוח. כתובת זו מוקצה על ידי המערכת הלקוח לאחר ווידוא קיום רשת IPv6 ומאושרת על ידי הנתב (אם פיצ'ר הפרטיות פעיל גם בצד שלו, אחרת היא לא תנותב). הכתובת זמינה ישר מבחוץ האינטרנט. הכתובת תוקצה על ידי הלקוח ותאושר בדרך כלל למשך יום, אך תישמר למשך שבוע מתגלגל אצל הלקוח והנתב זמנית ישמור routes לכתובות זמניות אלו כדי לאפשר תוכן נכנס (!) בכתובת "ישנה" לשבוע או הזמן שרונפג לשמירה זו. הכתובת אשר באמצעותה תזדהה למשאבי אינטרנט הציבורי בחיבור יוצא (!) יזום, תהיה הכתובת הכי חדשה בין כל כתובות הזמניות האלו - גם (!) אם הוגדרה כתובת DHCPV6 בנוסף לכתובת הזמנית.
ווידוא שאין ברשת כבר לקוח עם אותה כתובת, מבוצע על ידי multicast כפי שצוין למשל כאן http://gestioip.net/docu/ipv6_address_examples.html למטה
1. כתובת טווח fe80::/10 וסיומת שתלויה ב-MAC של הלקוח. הגדרה https://tools.ietf.org/html/rfc4291#section-2.5.6 . אין תקשורת לאינטרנט, אבל יש תקשורת באותה הרשת הפנימית - ניתן לתקשר עם לקוח אחר ברשת הפנימית הישירה (link-local) (אשר זמינה בפקודת arp -a אשר בהשוואה ל-ipv4 אמור לקבל את כל מה שרואים מ-broadcast דרך כתובת המסכה). היא תחזיק לעד, למעשה ניתן להתייחס לזה גם ככתובות הקצאה קבועה של DHCPv4 ברשת פנימית rfc1918 וגם כאל כתובות 169.254/16 של IPv4 לקונפיגורציה אוטומטית כאשר אין כתובת טובה יותר כאמור.
2. כתובת שניה, מוקצית SLAAC על ידי הנתב והמערכת:
2.1. כאשר פיצ'ר הפרטיות rfc4941 כבוי, מועתק מאותה הכתובת הפנימית של fe80, אל תוך הטווח הציבורי 64/ שקיבלת מהספק. במקרה זה הוא קבוע, וזמין מהאינטרנט ומזהה אותך לפי MAC ישר
2.2. כאשר הפיצ'ר לעיל פועל (תלוי בהגדרות נתב/מערכת, וזה לא בהכרח דבר נגיש להגדרה על ידי משתמש דרך דף הגדרות נתב או הגדרות לקוח, בדרך כלל זה פועל, אבל יש מכשירים שאצלם זה כבוי ללא אפשרויות קינפוג, ולשינוי מצריך קושחא מתואמת אישית וקינפוג ב-ssh ו/או במקרה של לקוח, חיטוט ב-regedit או קבצי קונפיג לינוקסאים) מורכב מכתובת ספק (הטווח שלך) פלוס גרסה "ערוכה" של כתובת סעיף 2.1 באופן כזה שלא מאפשר זיהוי MAC של הלקוח. כתובת זו מוקצה על ידי המערכת הלקוח לאחר ווידוא קיום רשת IPv6 ומאושרת על ידי הנתב (אם פיצ'ר הפרטיות פעיל גם בצד שלו, אחרת היא לא תנותב). הכתובת זמינה ישר מבחוץ האינטרנט. הכתובת תוקצה על ידי הלקוח ותאושר בדרך כלל למשך יום, אך תישמר למשך שבוע מתגלגל אצל הלקוח והנתב זמנית ישמור routes לכתובות זמניות אלו כדי לאפשר תוכן נכנס (!) בכתובת "ישנה" לשבוע או הזמן שרונפג לשמירה זו. הכתובת אשר באמצעותה תזדהה למשאבי אינטרנט הציבורי בחיבור יוצא (!) יזום, תהיה הכתובת הכי חדשה בין כל כתובות הזמניות האלו - גם (!) אם הוגדרה כתובת DHCPV6 בנוסף לכתובת הזמנית.
ווידוא שאין ברשת כבר לקוח עם אותה כתובת, מבוצע על ידי multicast כפי שצוין למשל כאן http://gestioip.net/docu/ipv6_address_examples.html למטה
אין NAT ורשתות פנימיות, כל מכשיר וכל ממשק רשת מקבל כתובת
ציבורית, הטווח שמגדירים בנתב ל-6 בד"כ 64/, אחר כך הכל תלוי בהגדרות DHCPv6. בין אם להקצות דינאמית ללקוחות (מחשב או טלפון שמתחבר לנתב זה גם "לקוח" לעניין זה), או להקצות כתובת ספציפית קבועה לכל DUID של כל ממשק ברשת שלך
ציבורית, הטווח שמגדירים בנתב ל-6 בד"כ 64/, אחר כך הכל תלוי בהגדרות DHCPv6. בין אם להקצות דינאמית ללקוחות (מחשב או טלפון שמתחבר לנתב זה גם "לקוח" לעניין זה), או להקצות כתובת ספציפית קבועה לכל DUID של כל ממשק ברשת שלך
אין סיבה לספק לשנות טווח 64/ אשר ניתנה, אך אם זאת
אם אתה מקבל את הכתובות SLAAC מהנתב, אתה מקבל כמה כתובות,
אחת מבוססת MAC דרך EUI-64 לשימוש פנים רשתי link-local (המקביל לטווח 169.254/16 ב-IPv4, אלא רק שב-IPv4 כתובת כזו מוקצית רק בתנאי שאין כתובת טובה יותר, וב-IPv6 כתובת כזו בטווח fe80::/10 תמיד מוקצית לפי MAC),
וכתובת שמשתנה לשימוש ציבורי (לחץ "פרטים.." במאפיינים שהצגת), זמן הקצאת SLAAC מגדירים בנתב
וכתובת שלישית אם (ורק אם) תקבע כזו מהטווח 64/ שלך ב-DHCPv6 לפי DUID של כרטיס הרשת של הלקוח (מקביל להגדרת כתובת קבועה ברשת הפנימית ב-IPv4, כלומר DHCP static leases) - אבל לא כל לקוח יכול לקבל כתובת DHCPv6 ולכן אם SLAAC פועל מקבלים את שני סוגי הכתובות יחד כאשר כתובת SLAAC בעדיפות גבוהה יותר לזמינות מבחוץ (בפשטות - לאתרים כמו whatismyip למשל, אבל עקרונית לכל משאב ברשת IPv6 כתובת SLAAC בעדיפות גבוהה יותר מ-DHCPv6) למרות שגם הכתובת שקבעת מ-DHCPv6 גם זמינה מבחוץ בנוסף לכתובת SLAAC בעדיפות שניה ואם הפורטים פתוחים - זכור שכל כתובת 128/ מלאה מגיעה ישר למכשיר, ולא מסתיימת בנתב שמנתב IPv4 דרך NAT ותלוי מהעברות פורטים ו-uPnP. כלומר במילים אחרות - ב-IPv6 אתה זמין ישר ותלוי ב-firewall במערכת שלך בלבד, כאילו שב-IPv4 הפעלת גישור או DMZ.
אם אתה מקבל את הכתובות SLAAC מהנתב, אתה מקבל כמה כתובות,
אחת מבוססת MAC דרך EUI-64 לשימוש פנים רשתי link-local (המקביל לטווח 169.254/16 ב-IPv4, אלא רק שב-IPv4 כתובת כזו מוקצית רק בתנאי שאין כתובת טובה יותר, וב-IPv6 כתובת כזו בטווח fe80::/10 תמיד מוקצית לפי MAC),
וכתובת שמשתנה לשימוש ציבורי (לחץ "פרטים.." במאפיינים שהצגת), זמן הקצאת SLAAC מגדירים בנתב
וכתובת שלישית אם (ורק אם) תקבע כזו מהטווח 64/ שלך ב-DHCPv6 לפי DUID של כרטיס הרשת של הלקוח (מקביל להגדרת כתובת קבועה ברשת הפנימית ב-IPv4, כלומר DHCP static leases) - אבל לא כל לקוח יכול לקבל כתובת DHCPv6 ולכן אם SLAAC פועל מקבלים את שני סוגי הכתובות יחד כאשר כתובת SLAAC בעדיפות גבוהה יותר לזמינות מבחוץ (בפשטות - לאתרים כמו whatismyip למשל, אבל עקרונית לכל משאב ברשת IPv6 כתובת SLAAC בעדיפות גבוהה יותר מ-DHCPv6) למרות שגם הכתובת שקבעת מ-DHCPv6 גם זמינה מבחוץ בנוסף לכתובת SLAAC בעדיפות שניה ואם הפורטים פתוחים - זכור שכל כתובת 128/ מלאה מגיעה ישר למכשיר, ולא מסתיימת בנתב שמנתב IPv4 דרך NAT ותלוי מהעברות פורטים ו-uPnP. כלומר במילים אחרות - ב-IPv6 אתה זמין ישר ותלוי ב-firewall במערכת שלך בלבד, כאילו שב-IPv4 הפעלת גישור או DMZ.
Copyright©1996-2021,Tapuz Media Ltd. Forum software by XenForo® © 2010-2020 XenForo Ltd.