שלום חברים..

הפעם  קצת על IPV6.. 

Link Local Addressing:

כתובות IPv6 Link Local מקבלות משמעות רק בסגמנט המקומי על גבי קישור בודד.

מה שזה אומר שתעבורה עם כתובות Link Local אינן יכולות לעבור בין סגמנטים (Routed), וכתובות Link Local יכולות להיות חופפות כל עוד הם קיימות על ממשקים שונים.

פורמט הכתובות של IPv6 Link Local הוא:

FE80::/10

והם בעלי משמעות נרדפת לכתובות ה-169.254.0.0/16  ב-IPv4.

פקטות עם כתובת מקור או יעד של Link Local בדרך כלל נמצאות בשימוש על ידי נתבים לטובת פרוטוקולי ה-Control Plane, כגון פרוטוקולי ניתוב IPv6.

עבור סגמנטים של broadcast כגון: Ethernet, הקישוריות המקומית היא מוחלטת זאת בעקבות השימוש האוטומטי בפרוטוקול ICMPND (ICMP Neighbor Discovery)

אך יחד עם זאת מכיוון שענני Multipoint NBMA  אינם תומכים ב-ICMP ND הפוך, יש צורך לוודא קישוריות ב-Link Local על גבי כתובות IPv6 על גבי קישורים אלו באמצעות הגדרת מיפויים סטטיים.

ללא הגדרת מיפויים אלו, פרוטוקולי הניתוב אינם יכולים ליצור קשרי שכנות, או לבצע אנקפסולציה בהתאם.

ההגדרות לביצוע מיפויים והגדרת כתובות IP מבוצע באופן הבא:

  ipv6 address fe80::5 link-local

  frame-relay map ipv6 fe80::1 501 broadcast

Unique Local Addressing:

כתובות Unique-Local ב-IPv6  או ULA, מוגדרות ב-RFC שמספרו 4193, שהוא מגיע והחליף את התקן הקודם שהגדיר את כתובות ה- Unique-Local ככתובות (FEC0::/10     ).

כתובות ULA ב- IPv6 מוגדרות בהקבלה לכתובות בתקן RFC 1918 אשר מגדיר את כתובות ה-IP הפרטיות ב- IPv4, לדוגמא כתובות -  10.0.0.0/8 או 172.16.0.0/12  או לחילופין 192.168.0.0/16.

כתובות ULA אינן ניתנות לניתוב על גבי האינטרנט.

הפורמט של ULA הוא באופן הבא:

FC00 (7 bits) + Unique ID (41 bits) + Link ID (16 bits) + Interface ID (64 bits)

יצירת ה-Unique ID באופן אקראי עוזרת להמנע מהתנגשויות בכתובות.

מעבר לפורמט הכתובות, פורמט ה-ULA  מפגין לא אחר מאשר התנהגות כתובות IPv6 אשר ניתן לבצע בהם ניתוב על גבי האינטרנט.

ההגדרה תחת הממשק מבוצעת באופן הבא:

 ipv6 address fc00:1:0:37::3/64

IPv6 Global Aggregateable Addressing:

כתובות ה-Globally Aggregateable  ידועות גם בשם  Global Unicast Address אשר מתחילות עם ערך בינארי של 001 (2000::/3), ואי לכך תופס את הטווח של 2000:: - 3FFF::  

להלן טבלת המרות מ-Hexadecimal ל-בינארי ולדצימלי:

 IPv6 EUI-64:

כתובות ה-Extended Unique Identifier הוא ערך של 64 ביטים אשר מוצמדים לממשק הפיזי.

ה-EUI הוא דומה מאוד לכתובת ה- IEEE MAC על ידי הזהות של הממשק הפיזי, אך ה-EUI תוכנן על מנת להיות בשימוש אוניברסלי ולא רק לטובת כתובות חומרה.

כתובות IPv6 משתמשות ב-EUI-64 על מנת לבנות כתובת Host ייחודית על גבי סגמנט משותף בצורה אוטומטית.

כאשר אנחנו משתמשים במילת ה-eui-64, ה-IOS משתמש ב-48 bit של הממשק החומרתי כבסיס לבניית הכתובת הייחודית של ה-64 של כתובת ה-IPv6.

במיוחד דבר זה מושג על ידי המרה של הביט ה-7 שהוא MSB מתוך ה-MAC Address, שנקרא Universal/Local (U/L bit) ואז להכניס 16 ביטים בפורמט של FFFE באמצע.

הגדרת כתובת IPv6 בפורמט של EUI-64 מבוצע באופן הבא:

 ipv6 address 2001:1:0:146::/64 eui-64

IPv6 Auto Configuration:

לפרוטוקול IPv6 ישנה פונקציה מיוחדת שנקראת Auto-Configuration.

היא מחליפה שימושים רבים שנמצאים בשירות על ידי DHCP ברשתות IPv4 ( עדיין קיימת גרסה מיוחדת של DHCPv6 בתוך פרוטוקול DHCP).

יחד עם IPv6 Auto-Configuration, מחשב שהוא מוגדר  לעבוד ב-IPv6 יכול בצורה אוטו' ללמוד ניתובים שהוקצו בסגמנט המקומי, ובנוסף גם לקבוע את ה-DG עבור אותו סגמנט.

סוג מיוחד של כתובת IPv6 Link-Local וסוג מיוחד של פרוטוקול ICMPv6 ND    (Neighbor Discovery) נמצאים בשימוש לטובת השגת מטרה זו.

הודעת פרסום נתב (Router Advertisement) יכולה להישלח בתזמון ספציפי או שניתן לדחוק את ההודעה בצורה מלאה (פונקציית ה-Suppress-ra מופעלת כברירת מחדל על גבי ממשקי Ethernet, התנהגות זו יכולה להשתנות על ידי פקודת

no ipv6 nd suppress-ra

כמובן שכל זאת תלוי כיצד אנחנו מגדירים את הנתב להתנהג.

** שים לב שחובה להפעיל IPv6 Unicast-Routing    על מנת לשלוח הודעות Router Advertisement.

הפקודות הבאות שולטות על הודעות ה-IPv6 RA:

הודעה זו שולטת על התזמון המחזורי של שליחת ההודעות:

ipv6 nd ra-interval

הודעה זו שולטת על התוקף של כתובת ה-IPv6 של הנתב:

ipv6 nd ra-lifetime

הודעה זו מבצעת מניפולציות על הכתובות הרלוונטיות שיכללו בתוך הודעת ה-RA,

כברירת מחדל כל הניתובים נכללים ב-RA:

ipv6 nd prefix

אנחנו יכולים לכוונן את החלון זמן שבו הניתוב תקף ומועדף.

בנוסף אנחנו יכולים להורות ל-Hostים שלא להשתמש בניתוב זה עבור Auto Configuration על ידי שימוש במילה

no-autoconfig

ההגדרות שיש לבצע הם:

DHCP SERVER:

  ipv6 nd prefix fc00:1:0:58::/64 14400 14400 no-autoconfig

  ipv6 nd prefix fc00:1:0:85::/64 14400 14400

  ipv6 nd ra-interval 40

  ipv6 nd ra-lifetime 60

  no ipv6 nd suppress-ra

DHCP CLIENT:

ipv6 address autoconfig default

 IPv6 NAT-PT:

אופציית ה-IPv6 NAT PT מאפשר לדומיינים של -IPv6 ול-IPv4 לתקשר על ידי שכתוב של ה- Packet Header והחלפת כתובות ה-IP.

בניגוד ל-NAT ב-IPv4 גם כתובת המקור וגם היעד של כל פקטה חייבת להיות משוכתבת מחדש.

במיוחד, IPv6 NAT-PT עובד באופן הבא:

קבוצה של כתובות IPv6 מייצגות טווח כתובות IPv4.

לקבוצה הזו בדרך כלל יש אורך מסכה של 96/, על מנת לכסות את כל ה- 2^32 כתובות של IPv4, אבל אחרת זה יכול להיות מספר שרירותי.

במידת הצורך אנחנו יכולים למפות כתובות IPv4 נבחרות לכתובות IPv6  בהתאמה, זאת באמצעות חוקי תרגום סטטיים.

כאשר מחשב IPv6 צריך לתקשר עם מחשב IPv4, הוא שולח פקטת IPv6 אל הכתובת שנמצאת בטווח של ה-  /96.

הנתב המתרגם מיירט את הפקטה שהולכת אל הניתוב של ה- 96/, ומחליפה את ה-IPv6 Header עם IPv4 Header, משכתבת מחדש גם את כתובת המקור וגם את כתובת היעד של ה-IPv6 עם זה של IPv4.

כאשר תגובת IPv4 חוזרת הנתב מבצע תרגום הפוך.

על מנת להגדיר NAT-PT אנחנו צריכים לציין את הדברים הבאים:

1.      חוקים לתרגום כתובת המקור ב- IPv4 לכתובות IPv6.

2.      חוקים לתרגום כתובת המקור ב- IPv6 לכתובות IPv4.

3.      ניתוב ה- /96 למיפוי טווח כתובות ה-IPv4.

ההגדרות של NAT-PT מבוצעות באופן הבא:

ipv6 nat

!

ipv6 nat v6v4 source fc00:1:0:67::7 155.1.146.7

ipv6 nat v4v6 source 150.1.4.4 2000::9601:0404

!

ipv6 nat prefix 2000::/96

IPv6 MP-BGP:

התוספת של MP-BGP מוסיפה תמיכה לטובת IPv6 באמצעות שימוש ב-Address-Family, מה שאומר באופן עקרוני הוא שניתובי IPv6 ומאפייניו יכולים לעבור על גבי קישור TCP רגיל בהתבסס על קשרי BGP.

אנחנו הגדרנו קשרי שכנות BGP  באמצעות IPv6 תחת תהליך ה-BGP באמצעות הפקודה:

address-family ipv6 unicast

לאחר מכן צריך לבצע Activate/ Enable על מנת להפעיל את השכן.

טכנית זהו אותו אופן בו אנחנו משתמשים לטובת הקמת קשרי שכנות ב-IPv4, אבל התהליך הגלובלי הרגיל מתייחס באופן אוטומטי ל- Address-Family ipv4 unicast, והפקודה bgp default ipv4-unicast מופעלת כברירת מחדל, מה שאומר שכל שכני ה- IPv4 Unicast פעילים כברירת מחדל.

ההגדרות של כל האופציות הרלוונטיות ל-IPv6 לוקחות שליטה תחת ה- Address-Family , כגון הגדרות Network, או שיוך מאפיינים לשכנים כגון: Route-Maps, Prefix-Lists, Filter-List וכו'..

חשוב לזכור שכל שאר פעולות ה- BGP ממשיכות לפעול באותו האופן, כגון- חוקי פרסום רשתות Route-Reflection, בחירת הנתיב הטוב ביותר, Confederation, וכו'...

בעיקר הדבר היחיד שהשתנה הוא הפורמט של הניתובים ופרסום ה-Next-Hop  שמופצים בתוך עדכון BGP.

שים לב שבקשרי שכנות מסוג EBGP ערך ה-Next-Hop  משוייך לכתובת ה-Link Local בתוך טבלת הניתוב, משמע שאשר אנחנו מקימים קשרי שכנות על גבי NBMA Multipoint, אנחנו חייבים למפות את כתובת ה-IPv6 של ה-Link Local .

ביצוע סיכום ניתובים (Summarization) נשאר אם אותה הפקודה ועם אותו אורך של חישוב ה-Mask.

אלו הפקודות להקמת קשרי שכנות MP-BGP:

  address-family ipv6 unicast   -------  IPV6 MP-BGP

  neighbor 2001:1:0:1234::5 remote-as 500

  neighbor 2001:1:0:1234::5 activate

  network 2003:1:0:1::/64

  network 2003:1:0:10::/61

  aggregate-address 2003:1::/59 summary-only

סיכום הניתובים בוצע בצורה כזו שלקחנו את כל הביטים הדומים,

אם נזכור, כל 4 מספרים שווים ל-16 ביטים, אזי השוני שלנו קיים באוקטט השלישי (חשוב לשים לב שה-MASK שלנו בכתובת השניה הוא 61/ ולא 64/)

IPv6 PIM & MLD:

ב-IPv4 ישנו טווח ספציפי של כתובות השמור לטובת שימוש Multicast (224.0.0.0 -239.255.255.255).

ב-IPv6 כתובות Multicast הם כל הכתובות שנמצאות בטווח של רשת FF00::/8.

במילים אחרות, כתובת IPv6 היא כתובת Multicast, אך ורק אם ה-Byte הראשון הוא FF (שווה ל-255 בדצימלי).

כתובת IPv6 היא באורך של 128 bit וביטים אלו מחולקים לקבוצות אשר מיועדות לציין דברים ספציפיים.

אחרי שמונת הביטים (שמציין את כתובת ה-Multicast), ישנם 4 ביטים כל אחד אשר מציינים דגל וקבוצה.

מה שמשאיר אותנו עם 112 ביטים לטובת ה-Group ID, ובגלל הטווח המאוד רחב של IPv6 טווח הכתובות הוא מאסיבי בהשוואה לכתובות IPv4.

כעת אנחנו נסתכל על דגלי הביטים.

נכון לעכשיו, שלושת הביטים הראשונים מתוך הארבעה ללא שימוש.

הדגל בביט הרביעי נקרא "ביט ארעי" (Transient), מטרתו היא לציין בין אם הכתובת היא קבועה או זמנית.

אם הכתובת היא מוקצית באופן קבוע (מוגדר על ידי IANA), אזי הביט הזה שווה ל-0.

אך לעומת זאת אם הביט הארעי הוא שווה ל-1 אזי הכתובת היא זמנית (או ארעית) .

דוגמא מושלמת של כתובות קבועות יכולות להיות:

FF02::2 -  All Routers.

FF02::6 – OSPF DR Routers.

ארבעת הביטים הנותרים שמעניינים אותנו בכתובת ה-Multicast ידועים כ- Scope ID bits.

ישנם 16 קומבינציות שונות שיכולים להיווצר באמצעות ארבעת הביטים הללו.

לא כל ה-16 נמצאים כעת בשימוש, אך שבעה מהם נמצאים בשימוש על מנת לקבוע את טווח הכתובות.

כדוגמא, אם טווח הכתובות הוא 1110 או גלובלי, אזי הכתובת היא ברת תוקף להיות מנותבת על גבי האינטרנט.

אלו הם הטווחים שמוגדרים כעת:

Decimal Value                Binary Value            Address Scope

0                                             0000                    Reserved

1                                             0001                    Node-Local Scope

2                                             0010                    Link-Local Scope

5                                             0101                    Site-Local Scope

8                                             1000                    Organization Local Scope

14                                           1110                    Global Scope

15                                           1111                    Reserved

חשוב מאוד לציין שכפייה של דגלים מסויימים והצפה של טווחים אינה תופסת מקום ברמת תוכנתית בשום מצב.

בנוסף לכך, הצפת טווח כתובות בכפייה צריכה להיות מוגדרת על ידי מנהל הרשת באמצעות Multicast Filtering.

רוב השימוש ב-Multicast ב-IPv6 דומה מאוד לזו שקיימת ב-IPv4, עם מספר שינויים.

גרסת PIMv2 עבור IPv6 דומה מאוד לתקן הסטנדרטי של PIMv2, רק שכאן הוא תומך רק בשיטת Sparse-Mode.

אין אפשרות להשתמש בגרסאות Dense-Mode על מנת להפיץ את מידע ה-Multicast.

פקודות רבות מתוך ה-IPv4 PIMv2  והקונספטים זהים לאלו של IPv6 כולל DR, ASSERT ו- RP.

פרוטוקול IPv6 משתמש בטבלת ה-unicast routing table (RIB) לטובת ביצוע בדיקות RPF אל מול מקורות Multicast.

משמע שהפצת תעבורת Multicast עבור IPv6 לוקחת פיקוד באותה צורה שבה היה מבוצע ב-IPv4.

ברגע שאנחנו מקלידים את הפקודה:

ipv6 multicast-routing

פרוטוקול PIMv6 הופך להיות פעיל עבור על הממשקים שעליהם פועל IPv6.

אנחנו יכולים לבטל את פונקציה זו על ידי שימוש בפקודה תחת הממשקים הרלוונטיים:

no ipv6 pim

כרגיל, כל הממשקים שמופעל עליהם PIM מתחילים להציף תעבורת Multicast על מנת ליצור עצים.

פרוטוקול MLD:

או -  Multicast Listener Discovery , מבוסס על פרוטוקול ICMPv6 ומחליף את פרוטוקול IGMP.

פרוטוקול IGMP הוא פרוטוקול סימון לקבוצה אשר נמצא בשימוש ב-IPv4 לטובת Multicast.

גרסת MLDv1 מתורגמת ל- IGMPv2 ו-MLDv2 מתורגמת לגרסת IGMPv3, מאפשרת לציין מקור מסויים עבור תעבורת IPv6 Multicast.

פרוטוקול MLD תומך בשלושה סוגי הודעות בדומה מאוד להודעות IGMP[ והם:

·         Query.

·         Report.

·         Done – שהודעה זו זהה במהות שלה להודעת Leave ב-IGMPv2.

הגדרת MLD מאוד דומה להגדרת IGMP – אנחנו יכולים לציין מספר מקסימלי של קבוצות שהצטרפו על ידי מחשב מסויים על גבי ממשק באמצעות פקודה:

ipv6 mld limit

או להצטרף לקבוצה באמצעות פקודה:

ipv6 mld join-group

עוד אנחנו יכולים לציין פקודות רלוונטיות ל-MLD אשר מתייחסות לתשאול של השכנים באמצעות:

ipv6 mld query-interval

ipv6 mld query-timeout

ipv6 mld query-max-response-time

זמני ה-MLD הם זהים לאלו שהיו ב-IGMPv2 או IGMPv3.

שימו לב לשימוש ב-IPv6 ACL מטה על מנת לשלוט בקבוצות שמחשב יכול להצטרף אליהם.

רשומת ה-ACL:

} Permit | Deny}  ipv6 

מאפשר גם לסנן גם SSM וגם קבוצת Multicast רגילה.

אם אנחנו רוצים לפלטר רק הודעות Join של MLDv1, יש להשאיר את ה- <part 1> ב-Any  משמע זה מציין כל מקור.

הפרמטר שמוגדר ב- Part 2 אחראי על קבוצות ה-Multicast  שמצטרפות.

אזי אפשרי עם פילטר זה לאפשר או לחסום לאילו קבוצות Multicast ספציפיות יכולות להצטרף על ידי אילו Hosts.

ההגדרות של PIM והגדרות ה-MLD באופן הבא:

ipv6 access-list MLD_FILTER

 permit ipv6 any ff08:;/64

!

ipv6 mld access-group MLD_FILTER

ipv6 mld join-group ff08::8

ipv6 mld query-interval 10

IPv6 PIM BSR:

פרוטוקול IPv6 RP ו-BSR מאוד זהים לאלו שהיו להם ב-IPv4.

אך יחד עם זאת ישנם מספר שינויים בהגדרות .

הפקודה שהנתב מודיע על עצמו כ-RP האמצעות פרוטוקול BSR  היא:

ipv6 pim bsr candidate rp (NOT THE INTERFACE NAME)

הפקודה שבאמצעותה אנחנו גורמים לנתב להתחיל להפיץ הודעות RP Bootstrap  ולהשתתף בבחירות ה-BSR היא:

ipv6 pim bsr candidate bsr

כרגיל אנחנו יכולים להגדיר נתב אחד בודד שישמש כ-BSR וגם כ-RP.

פונקציה נוספת שקיימת ב-IPv6 BSR  היא שאנחנו יכולים להגדיר BSR עם רשימה של Candidate RP's באמצעות הפקודה:

ipv6 pim bsr announce rp

בכך אנחנו מגבילים את הצורך בהודעות דינמיות שנשלחות על ידי Candidates.

ההבדל היחיד המהותי בין IPv4 PIM ו- IPv6 PIM הוא תהליך רישום המקור.

כאשר מקור מסויים מתחיל לשדר Multicast, ה-DR על גבי אותו סגמנט אמור להירשם אל מול ה-RP.

תהליך זה בדרך כלל מבוצע על ידי שליחת הודעת PIM Register אל ה-RP וביצוע אנקפסולציה של המידע המקורי בתוך הפקטה.

ברגע שנתב IPv6 בעל יכולות Multicast לומד את כתובת ה-IP של ה-RP הוא יוצר ממשק TUNNEL ומקשר את הנתב אל

ה-RP.

על גבי ה-TUNNEL מופעל באופן אוטו' Multicast  כך שתעבורת Multicast נשלחת מטה במורד העץ פשוט מועברת על גבי הצינור לכיוון ה-RP.

ה-TUNNEL בשימוש רק לטובת תהליך הרישום, ולאחר מכן ה-Receivers הולכים אל הנתיב האופטימלי, שאינו חוצה את הצינור.

השימוש ב-Tunnel זה מאפשר הפצת תעבורה Multicast בצורה אחידה באמצעות שימוש באותו הקוד ושימוש בצינור לטובת  הודעות הרישום של PIM אל מול ה-RP.

אנחנו יכולים לראות את הרשימה של ה-Tunnelים  הפעילים באמצעות פקודה:

show ipv6 pim tunnel

אנחנו יכולים לוודא הגדרות ה-BSR ומי הוא ה-RP באמצעות פקודה:

show ipv6 pim bsr election

או  לחילופין להשתמש בפקודה הבאה על מנת לצפות במיפוי של ה-RP לרשימת הקבוצות:

show ipv6 pim bsr election

 IPv6 Embedded RP:

ישנה פונקציה אחת שזמינה ב-IPv4 Multicast ואינה זמינה נכון לעכשיו ב- IPv6.

פונקציית ה-Auto-RP היא טכנולוגיה אשר נתבים יכולים להיות מוגדרים כ- Candidate RP, עבור כל קבוצות ה-Multicast שנבחרו.

הם מפיצים את עצמם באמצעות כתובת Multicast 224.0.1.39.

נכון לעכשיו Auto-RP אינו זמין בגרסת IPv6.

בנוסף אין שום דבר שדומה ל- Multicast Source Discovery Protocol (MSDP)  בגרסת IPv6 .

גרסת IPv6 Embedded RP היא פתרון אחד שאנחנו יכולים להשתמש כאשר אנחנו נדרשים לתמוך במודל ה-PIM SM דרך מספר דומיינים.

קודם לכן, דנו בדגלי הביטים בתוך כתובות IPv6.

הסברנו שתחת נסיבות הרגילות שלושת הביטים הראשונים תמיד היו 000.

כאשר אנחנו משתמשים בפונקציית ה- Embedded RP מצב זה משתנה, ואז הביט השני, השלישי והרביעי הופכים להיות 1.

הסברנו גם את התפקוד של הביט הרביעי  (הארעי) , כעת אנחנו מסתכלים על הביט השני והשלישי.

הביט השני הוא R ביט וכאשר הוא מוצב עם ערך של 1, הוא מציין שה- 4-Bit RP Interface ID למעשה נעוץ בתוך כתובת הקבוצה.

הביט השלישי הוא P ביט וכאשר הוא מוצב עם ערך של 1 הוא מציין ש- 64 ביטים של כתובת ה- RP נעוצים בתוך כתובת

ה-Multicast.

כעת עם P, R  ו- T ביטים מוצבים לערך של 1, במקום להישען על המידע שמופץ מה-BSR , השולחים והמקבלים מסכימים לנעוץ את כתובת ה-RP IPv6 לתוך כתובת ה-Multicast עצמה.

הכתובת לוקחת את הצורה הבאה:

FF7x:0yLL:PPPP:PPPP:PPPP:PPPP: <32 bit-group-id="bit-group-id">

כאשר אנחנו מסתכלים על ערך ה- FF7 במספר הקסדצימלי הוא ערך של 1111 1111 0111 , וה-x הוא ה-4 ביטים של

ה-Scope,  ערך ה-y הוא ה- 4 bit RP Interface ID, ערך ה-LL הוא 8 bit prefix וה- PPPP:PPPP:PPPP:PPPP הם 64 ביטים של ה-RP Prefix.

כתובת ה-RP עצמה נלקחת על ידי לקיחה של ה-Prefix, ולהסתיר אותה באמצעות ה-LL.

ה-Interface-ID אינו יכול להיות 0, אזי הוא כל ערך מ-0 ועד F (כל המספרים הם ב-HEX).

אזי הנתב שאמור להיות ה-RP עם הכתובת הזו חייב להחזיק ממשק Loopback  עם הכתובת הזו ולהפיץ אותה אל תוך הפרוטוקול , כך שכל הנתבים יוכלו להגיע אליה.

במקרה שלנו בחרנו את כתובת הקבוצה   FF76:0640:2001:CC1E::8 אשר מקבילה לכתובת ה-RP של 2001:CC1E::6/64.

שאותה הפצנו מנתב R6.

ההגדרות של Embedded RP מבוצעות באופן הבא:

R5:

  ipv6 mld join-group ff76:0640:2001:CC1E::8

!

R6:

ipv6 address 2001:CC1E::6/128

ipv6 eigrp 100

ipv6 rip RIPNG enable

IPv6 SSM:

פרוטוקול SSM או  Source Specific Multicast הוא הצורה הפשוטה ביותר של Multicasting .

המקבל מציין רשימה של מקורות שמהם הוא מעוניין לקבל תעבורת Multicast בנוסף לקבוצות באמצעות הודעות MLD Report.

נתב ה-Multicast בונה את העץ הקצר ביותר אל עבר המקור שמשדר את ה-Multicast אשר צוין בתוך הודעת ה-Report, והשולח יתחיל להעביר תעבורה.

אין צורך ב-RP בעת שימוש ב-SSM.

למעשה קבוצות בתוך טווח  IPv6 SSM לעולם לא ימפו אליהם RP.

ישנו טווח מיוחד ל-SSM שהוא FF3x::/96.

שהוא מאפשר 2^32 קבוצות Multicast פר שולח.

אנחנו יכולים לסנן את המקורות שהמאזין יכול להצטרף אליהם באמצעות הפקודה תחת ה-MLD:

ipv6 mld access-group

כאשר אנחנו משתמשים ב-ACL על מנת לתחום את המקורות ואת טווחי הקבוצות.

הגדרות ה-SSM מבוצעות באופן הבא:

  ipv6 mld join-group ff36::8  2001:1:0:146:21A:2FFF:FE78:4678

IPv6 Tunneling:

אנחנו יכולים להעביר תעבורת IPv6 על גבי ענן IPv4 באמצעות מספר טכנולוגיות Tunneling שונות.

השיטה הנפוצה ביותר היא שימוש באמצעות Point-To-Point Tunnels, או באמצעות שימוש ב-GRE או לחילופין ביצוע אנקפסולציה של IPv6 in IPv4 (סוג פרוטוקול מיוחד שתוכנן לשאת פקטות IPv6 בלבד).

זהו צינור שמוגדר עם כתובת מקור וכתובת יעד ב-IPv4 אבל נושא כתובות IPv6.

הגדרות ה-tunneling הם באופן הבא:

R2 – R6:

ipv6 unicast-routing

!

  ipv6 address 2001:1:0:2::2/64

!

  tunnel source loopback 0

  tunnel destination 150.1.6.6

  ipv6 address 2001:1:0:26::2/64

!

ipv6 route ::/0 tunnel 26

R5 – R6:

ipv6 unicast-routing

!

  ipv6 address 2001:1:0:5::5/64

!

  tunnel source loopback 0

  tunnel destination 150.1.6.6

  ipv6 address 2001:1:0:56::5/64

TUNNEL MODE IPV6IP

!

ipv6 route ::/0 tunnel 26

בהצלחה!

מקווה שעזרתי,

אבי