IPv6 Multicast. Rostislav Žólty, ZOL005 Jan Golasowski, GOL091

IPv6 Multicast Rostislav Žólty, ZOL005 Jan Golasowski, GOL091 Abstrakt: Tato práce se zabývá možnostmi skupinového vysílání nad protokolem IPv6. Jsou uvedeny potřebné teoretické informace o principu skupinového vysílání a dále rozdíly oproti protokolu IPv4. V práci je prakticky ověřena funkčnost a některé možnosti multicastu. Klíčová slova: IPv6, multicast, MLD, PIM, SSM, embedded RP 1 Multicast adresy v IPv6...2 1.1 Předdefinované adresy...2 2 Mapování IPv6 na MAC...2 3 Skupinové adresy založené na individuálních...2 4 Skupinové adresy pro SSM (Source Specific Multicast)...3 5 Protokoly pro registraci posluchačů...3 5.1 MLDv1...3 5.2 MLDv2...4 6 Skupinové směrovací protokoly...4 6.1 Protocol Independent Multicast (PIM)...5 6.1.1 PIM Sparse Mode (PIM-SM)...5 6.1.2 Source-Specific Multicast (PIM-SSM)...6 7 Praktické ověření IPv6 multicastu...6 7.1 Ukázka konfigurace routerů a stanic (Sparse mode s embedded RP)...6 7.2 Ukázka konfigurace routerů a stanic (PIM-SSM)...9 7.3 Výpisy z konzole (Sparse-mode s embedded RP)...10 7.4 Výpisy z konzole (PIM-SSM)...14 8 Závěr...17 9 Použitá literatura...18 duben 2009 1/18

1 Multicast adresy v IPv6 Adresy v IP protokolu verze 6 mají 128 bitů. Existuje tedy mnoho možností, jak tento velký adresní prostor využít ve skupinovém vysílání. Multicastová adresa se skládá z několika částí. Prvních 8 bitů je nastaveno na 1 adresa tedy začíná FF v hexadecimální soustavě. Následující 4 bity jsou volby nebo příznaky, kterými můžeme určit, zda je adresa dočasná nebo trvalá, zda vychází z lokálního prefixu nebo můžeme dalším příznakem vložit do multicastové adresy adresu rendezvous pointu. Další 4 bity určují dosah (může být v rámci sítě, uzlu, organizace apod.). Nejdůležitější částí je samozřejmě samotná adresa skupiny. Podobně jako v IPv4 multicastu jsou i v IPv6 multicastu vyhrazené adresy, které nesmíme přidělovat. Několik z nich je uvedeno zde: 1.1 Předdefinované adresy ff02::1 všechny uzly v rámci dané linky (odpovídá broadcastu) ff02::2 všechny směrovače v rámci dané linky ff02::16 všechny MLDv2 směrovače na lince 2 Mapování IPv6 na MAC Mapování skupinové IPv6 adresy na MAC adresu je odlišné od mapování IPv4 adres. První 2 bajty MAC adresy mají hodnotu 33, zbývající 4 bajty jsou poslední 4 bajty skupinové adresy. Například pro IPv6 adresu ff02::3:1122:aacc dostaneme MAC adresu 33:33:11:22:aa:cc. V případě, že by 2 počítače měly stejnou MAC skupinovou adresu, projdou rozhraním všechny rámce a až na úrovni IPv6 se vyřadí pakety, která nejsou určena pro danou IPv6 adresu. 3 Skupinové adresy založené na individuálních Určité množsví skupinových adres přiděluje IANA, část rozsahu je určen k volnému použití. Pro zajištění jednoznačnosti adresy však můžeme použít příznak P, kterým dáme najevo, že chceme vytvořit adresu založenou na individuální. Jednoznačnost je zajištěna prefixem přidělené individuální adresy sítě. Ten může být dlouhý 48 nebo 64 bitů. Posledních 32 bitů adresy slouží k identifikaci skupiny. Pokud je nastaven příznak P na 1, musí být stejně nastaven i příznak T, čímž řekneme, že se jedná o dočasnou adresu. Na Obrázku 1 je znázorněno, jakým způsobem se skupinové adresy založené na individuálních adresách vytváří. Obrázek 1: Skupinová adresa založená na individuální (převzato z [1]) Příklad: Pro prefix 2001:718:1c01::/48 chceme skupinovou adresu s dosahem 5 a skupinovým identifikátorem 7. Výsledná adresa je na Obrázku 2. duben 2009 2/18

Obrázek 2: Příklad skupinové adresy s příznakem P (převzato z [1]) 4 Skupinové adresy pro SSM (Source Specific Multicast) Tyto adresy slouží k přenosům z jednoho zdroje skupině příjemců. Skupinové adresy pro SSM jsou speciálním případem individuálních adres, s tím rozdílem, že délka prefixu a prefix sítě jsou nulové. Tyto adresy mají prefix ff3x::/96. Na Obrázku 3 je znázorněna struktura takové adresy. Obrázek 3: Skupinová adresa pro SSM (převzato z [1]) 5 Protokoly pro registraci posluchačů 5.1 MLDv1 Jedná se o protokol, který slouží ke stejným účelům jako IGMP pro IPv4, tedy registraci příjemců skupinového vysílání. MLD se vyskytuje ve dvou verzích. MLDv1 umožňuje hlášení o příjmu nějaké skupiny. MLD zprávy se zasílají směrovačům, kteří si tak ukládají seznam skupinových adres, pro které je na daném rozhraní alespoň jeden posluchač. Tyto informace slouží k sestavení distribučních stromů pro jednotlivé skupiny. Informace o odesilatelích v MLDv1 nejsou obsaženy, a proto nemůžeme volit mezi zdroji, které skupinová data vysílají. Protože MLD zprávy vycházejí ze zpráv ICMP, formát zprávy je podobný právě ICMP zprávám. Obsahuje zejména typ zprávy a skupinovou adresu. V položce Typ může být jedna ze tří hodnot 130 (výzva směrovače), 131 (hlášení stanice o členství ve skupině) a 132 (hlášení stanice o vystoupení ze skupiny). Celý formát zprávy je na Obrázku 4. Přidání do seznamu příjemců probíhá tak, že daná stanice zašle zprávu 131 na adresu skupiny, kterou chce poslouchat. Ukončení členství ve skupině se provádí zasláním zprávy 132, ovšem už ne na adresu skupiny, nýbrž na adresu ff02::2, což je skupinová adresa pro všechny routery na lince. Na zprávu 132 reagují směrovače dvěma způsoby. Pokud se naposledy přihlašoval do skupiny jiný počítač, než ten, který poslal zprávu 132, pak určitě existuje nějaký další posluchač, a proto si směrovač danou skupinovou adresu nechá v seznamu. Pokud ovšem poslal zprávu 132 ten počítač, který se jako poslední přihlašoval do skupiny, musí směrovač poslat zprávu 130 na adresu zjišťované skupiny. Aby nedošlo k zasílání mnoha odpovědí, nastaví si každý člen skupiny časovač na náhodné číslo (maximálně do výše hodnoty uvedené v poli Maximální zpoždění odpovědi). Po vypršení tohoto intervalu zašle počítač na adresu skupiny odpověď (ohlášení členství ve skupině). Ostatní počítače si tak časovače zruší a už odpověď posílat nebudou. Stačí tedy jediná odpověď. Zpráva typu 130 ovšem neslouží jen pro zjišťování posluchačů konkrétní skupiny, ale také pro případ, kdy se posluchač neodhlásí, tzn. zjištění, které skupiny mají nějaké posluchače. Pole Skupinová adresa je nulové, dotaz se zasílá na všechny uzly na lince (adresa ff02::1). Tyto dotazy posílá pouze jeden router na lince, abychom zabránili velkému množství zasílaných dotazů. Odpovědi ovšem zpracovávají všechny routery na duben 2009 3/18

lince a udržují tak konzistentní informace o skupinách a jejich posluchačích. Počítače odpovídají opět zprávou 131 s adresou skupiny, kterou chtějí poslouchat. Obrázek 4: Formát zprávy protokolu MLDv1 (převzato z [1]) 5.2 MLDv2 Oproti verzi 1 MLDv2 umožňuje navíc filtrovat zdroje, tzn. vybrat konkrétní zdroj dat nebo naopak příjem dat z některých adres blokovat. Filtrování se provádí pomocí INCLUDE a EXCLUDE. INCLUDE slouží k definování zdrojů, od kterých chceme přijímat, EXCLUDE naopak obsahuje seznam zdrojů, od kterých skupinová data přijímat nechceme. Jednotlivá pravidla můžeme kombinovat a provádět tak logické operace jako průnik, sjednocení nebo doplněk. Jednotlivé kombinace jsou na Obrázku 5. Obrázek 5: Pravidla kombinování filtrů (převzato z [1]) Ekvivalentní s MLDv1 jsou případy, kdy do závorky neuvedeme žádný zdroj. INCLUDE() znamená vystoupení ze skupiny, EXCLUDE() potom příjem skupinového vysílání ze všech zdrojů. MLDv2 má tedy na straně příjemce jen jednu událost typu 143 (Hlášení, neboli Report), které posílá všem MLDv2 směrovačům na lince (adresa ff02::16). Oproti MLDv1 se zpráva netýká pouze jedné skupiny, která byla uvedena v cílové adrese. Každá MLDv2 zpráva se skládá z tzv. záznamů, které nesou informace o skupinové adrese, zdrojích skupinového vysílání a typ záznamu (INCLUDE či EXCLUDE). Podobně jako u MLDv1 byla zpráva 130 pro dotaz směrovače na posluchače skupiny, existuje u MLDv2 podobný dotaz. Navíc umožňuje k dotazu připojit seznam zdrojů a zjistí tak nejen posluchače daných skupinových dat, ale také posluchače konkrétních zrojů. Směrovač posílá dotaz všem na adresu ff02::1 nebo na adresu konkrétní skupiny (blíže vysvětleno v praktické části). Odpovědi se neposílají na adresu skupiny jako u MLDv1, ale všem směrovačům. V odpovědi tak není pouze adresa jedné skupiny, ale seznam všech skupin a zdrojů, které příjemce poslouchá. Nestačí tedy jedno hlášení na skupinu, ale každý příjemce musí odeslat jedno hlášení. 6 Skupinové směrovací protokoly Při skupinovém směrování je nejdůležitější vybudování distribučního stromu, který bude co nejefektivněji přenášet data ke všem příjemcům. K tomuto účelu slouží právě skupinové směrovací protokoly, které takovýto strom vybudují. duben 2009 4/18

6.1 Protocol Independent Multicast (PIM) Stejně jako pro adresní prostor IPv4, i v IPv6 existuje skupina protokolů s názvem PIM. Dělí se na Sparse mode, Bidirectional a Source Specific Multicast. Dense mode už v IPv6 není. 6.1.1 PIM Sparse Mode (PIM-SM) Tento protokol se používá tam, kde jsou příjemci skupinového vysílání rozprostřeni řídce. Princip je takový, že skupinové vysílání se může dostat jen k těm, kteří o toto vysílání požádali. Tuto žádost posílá směrovač, kterému se ohlásil minimálně jeden posluchač. Směrovač pak tuto žádost pošle směrem k rendezvous pointu, kde se setkávají zdroje a příjemci skupinového vysílání. Pro každou skupinu se tvoří sdílený strom, který má jako kořen rendezvous point a větve dosahují do těch směrovačů, které se přihlásily k odběru dat. Distribuce dat probíhá tak, že zdroj pošle data, jeho přilehlý směrovač je zabalí do PIM zprávy a pošle na adresu rendezvous pointu. Tady se rozbalí a rozešle se sdíleným stromem ke všem příjemcům. Jak už bylo uvedeno, skupinové vysílání mohou přijímat pouze ti, kteří o něj požádali. Posluchači tak pravidelně posílají zprávy o tom, že chtějí poslouchat. Pokud tak neučiní, po nějaké době se ze sdíleného stromu odstraní přilehlý směrovač pošle žádost o odříznutí ze stromu. Sdílený strom je určen zejména směrovači poblíž zdrojů dat a jejich příjemců. Pokud je počítač připojen k více směrovačům, je potřeba zvolit jen jeden z nich. Takovýto směrovač se označuje jako tzv. designated router. V IPv6 můžeme využít velikost adresního prostoru k tomu, abychom adresu rendezvous pointu vložili přímo do skupinové IPv6 adresy (tento způsob šíření RP nazýváme embedded RP). Ze skupinové adresy tak počítač, který chce poslouchat, zjistí rendezvous point, na který má posílat žádosti o příjem skupinového vysílání. Výhodou tohoto řešení je to, že nemusíme na každém routeru nastavovat adresu RP. Skupinová adresa, která v sobě nese rendezvous point, má nastaven na jedničku příznak R a také příznaky P a T jsou rovny 1. Taková adresa tedy začíná prefixem ff7::/12. Na Obrázku 6 je znázorněna tvorba skupinové adresy RIID je identifikátor rozhraní (RP Interface ID) a nahrazuje původní spodní 4 bity rezervované pro budoucí využití. Adresa RP se odvodí tak, že jako začátek se vezme prefix sítě, koncem bude RIID a bity mezi těmito dvěma hodnotami budou nulové. Obrázek 6: Skupinová adresa obsahující rendezvous point (RP) (převzato z [1]) 7. Například pro prefix sítě 2001:718:1c01:19::8 bude skupinová adresa vypadat jako na Obrázku Obrázek 7: Příklad skupinové adresy obsahující RP (převzato z [1]) duben 2009 5/18

6.1.2 Source-Specific Multicast (PIM-SSM) SSM je rozdílný oproti Sparse mode v tom, že nepotřebuje rendezvous point. Žádosti se posílají přímo zdroji skupinového vysílání. Používá rozdílné označení dvojice (S, G) zdroj S, skupinová adresa G. V SSM se této dvojici říká kanál (channel). 7 Praktické ověření IPv6 multicastu Pro praktické ověření činnosti IPv6 multicastu jsme použili 4 routery Cisco 2800 a 3 pracovní stanice. Routery měly IOS verze 12.4. Na stanicích byl nainstalován OS Ubuntu 8.10 kernel 2.6.27-11 generic. Topologie i s nastavenými adresami a jednotlivými rozhraními je na Obrázku 8. Pro směrování v této síti jsme použili protokol RIPng. Pro testování skupinového provozu jsme použili program VLC. IPv6 multicast se zprovozní na jednotlivých routerech příkazem ipv6 multicast-routing. Výchozím režimem je PIM-SM a MLDv2. Jako rendezvous point jsme zvolili rozhraní s adresou 2001:2::2 skupinová adresa pro Sparse mode s embedded RP je tedy FF7e:240:2001:2::0:5. Pokud bychom začali rovnou vysílat na tuto skupinovou adresu, nic by se nedělo. Je nutné přiřadit k RP access list, který povoluje ipv6 přenos na adresu skupiny toto dodatečné nastavení je nutné provést pouze na routeru, který je právě RP. V konfiguraci routeru B proto vidíte tyto příkazy: ipv6 pim rp-address 2001:2::2 RP ipv6 access-list RP permit ipv6 any ff7e:240:2001:2::/64. PC 2-4 PC 2-3 FE 0/0 :1 :2 2001:E1::/64 A :1 S1/0 2001:2::/126 :2 S2/0 :1 S1/1 S1/0 B :1 2001:3::/126 2001:4::/126 :2 S1/0 C FE 0/0 :2 :1 2001:E2::/64 :1 FE0/1 2001:5::/126 FE0/1 :2 :2 :1 S1/0 2001:E3::/64 :2 G FE 0/0 PC 3-2 Obrázek 8: Topologie sítě 7.1 Ukázka konfigurace routerů a stanic (Sparse mode s embedded RP) Router A enable configure terminal hostname A ipv6 unicast routing interface serial 0/1/0 ipv6 address 2001:2::1/126 duben 2009 6/18

int fastethernet 0/0 ipv6 address 2001:E1::2/64 ipv6 multicast routing ipv6 router rip lab Router B enable configure terminal hostname B ipv6 unicast routing interface serial 0/2/0 ipv6 address 2001:2::2/126 int serial 0/1/1 ipv6 address 2001:3::1/126 int serial 0/1/0 ipv6 address 2001:4::1/126 ipv6 multicast routing ipv6 router rip lab ipv6 pim rp-address 2001:2::2 RP ipv6 access-list RP permit ipv6 any ff7e:240:2001:2::/64 Router C enable configure terminal hostname C duben 2009 7/18

ipv6 unicast routing interface serial 0/1/0 ipv6 address 2001:3::2/126 int fastethernet 0/0 ipv6 address 2001:E2::2/64 int fastethernet 0/1 ipv6 address 2001:5::1/126 ipv6 multicast routing ipv6 router rip lab Router G enable configure terminal hostname G ipv6 unicast routing interface serial 0/1/0 ipv6 address 2001:4::2/126 int fastethernet 0/0 ipv6 address 2001:E3::2/64 int fastethernet 0/1 ipv6 address 2001:5::2/126 ipv6 multicast routing ipv6 router rip lab duben 2009 8/18

Nastavení adresy a výchozí brány na PC 2-3 ifconfig eth0 inet6 add 2001:E1::1/64 route A inet6 add ::/0 gw 2001:E1::2 dev eth0 Nastavení adresy a výchozí brány na PC 2-4 ifconfig eth0 inet6 add 2001:E2::1/64 route A inet6 add ::/0 gw 2001:E2::2 dev eth0 Nastavení adresy a výchozí brány na PC 3-2 ifconfig eth0 inet6 add 2001:E3::1/64 route A inet6 add ::/0 gw 2001:E3::2 dev eth0 7.2 Ukázka konfigurace routerů a stanic (PIM-SSM) Oproti Sparse mode se v PIM-SSM nepoužívá RP, proto zde nevidíme ani nastavení RP, ani skupinovou adresu, která by adresu RP obsahovala. Uvedeme pouze konfiguraci routeru B (v případě statického mapování): ipv6 mld ssm-map enable ipv6 mld ssm-map static SSM 2001:E1::1 no ipv6 mld ssm-map query dns ipv6 access-list SSM permit ipv6 any host FF33::DEAD První příkaz slouží k povolení SSM, druhým konfigurujeme statické mapování (SSM je název access listu, 2001:E1::1 je adresa zdroje). Třetím příkazem zrušíme mapování pomocí DNS. Poslední 2 příkazy se týkají access listu, který je nutný pro chod SSM. Cílová adresa FF33::DEAD je skupinovou adresou. Router B enable configure terminal hostname B ipv6 unicast routing interface serial 0/2/0 ipv6 address 2001:2::2/126 int serial 0/1/1 ipv6 address 2001:3::1/126 int serial 0/1/0 ipv6 address 2001:4::1/126 duben 2009 9/18

ipv6 multicast routing ipv6 router rip lab ipv6 mld ssm-map enable ipv6 mld ssm-map static SSM 2001:E1::1 no ipv6 mld ssm-map query dns ipv6 access-list SSM permit ipv6 any host FF33::DEAD 7.3 Výpisy z konzole (Sparse-mode s embedded RP) Router A (show ipv6 mroute) Ve výpisu vidíme, že na rozhraní FastEthernet 0/0 přijímáme provoz ze stanice PC 2-3 (IP 2001:E1::1) na adresu skupiny FF7E:240:2001:2::5. Příznak S říká, že se jedná o Sparse mode. Odchozím rozhraním je serial 0/1/0. A#sh ipv6 mroute Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, I - Received Source Specific Host Report, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT Timers: Uptime/Expires Interface state: Interface, State (2001:E1::1, FF7E:240:2001:2::5), 00:30:10/00:01:38, flags: SFT Incoming interface: FastEthernet0/0 RPF nbr: 2001:E1::1 Immediate Outgoing interface list: Serial0/1/0, Forward, 00:08:24/00:03:05 Router A (debug ipv6 pim) Začátek vysílání je vidět v těchto zprávách zdroj 2001:E1::1 se připojuje do skupiny FF7E:240:2001:2::5 (zpráva join). Rozhraní serial 0/1/0 je odchozím rozhraním routeru A. *Jun 1 09:13:24.951: IPv6 PIM: J/P entry: Join root: 2001:E1::1 group: FF7E:240:2001:2::5 flags: S *Jun 1 09:13:24.951: IPv6 PIM: (2001:E1::1,FF7E:240:2001:2::5) Serial0/1/0 J/P state changed from Null to Join *Jun 1 09:13:24.951: IPv6 PIM: (2001:E1::1,FF7E:240:2001:2::5) Serial0/1/0 FWD state change from Prune to Forward Ukončení vysílání je vidět ze zprávy prune. Na odchozím rozhraním routeru A se mění stav z join na prune a skupinové vysílání ze zdroje 2001:E1::1 se tak rozhraním serial 0/1/0 nešíří. *Jun 1 09:13:31.995: IPv6 PIM: J/P entry: Prune root: 2001:E1::1 group: FF7E:240:2001:2::5 flags: S *Jun 1 09:13:31.995: IPv6 PIM: (2001:E1::1,FF7E:240:2001:2::5) Serial0/1/0 J/P state changed from Join to Null duben 2009 10/18

*Jun 1 09:13:31.995: IPv6 PIM: (2001:E1::1,FF7E:240:2001:2::5) Serial0/1/0 FWD state change from Forward to Prune Router B (show ipv6 mroute) Na routeru B je příchozím rozhraním serial 0/2/0, odchozí rozhraní má 2 (k routerům C a G) serial 0/1/1 a serial 0/1/0. B#show ipv6 mroute Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, I - Received Source Specific Host Report, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT Timers: Uptime/Expires Interface state: Interface, State (*, FF7E:240:2001:2::5), 00:07:09/00:02:58, RP 2001:2::2, flags: S Incoming interface: Tunnel4 RPF nbr: 2001:2::2 Immediate Outgoing interface list: Serial0/1/1, Forward, 00:00:31/00:02:58 Serial0/1/0, Forward, 00:07:09/00:00:19 (2001:E1::1, FF7E:240:2001:2::5), 00:28:54/00:03:14, flags: ST Incoming interface: Serial0/2/0 RPF nbr: FE80::222:55FF:FEA2:3892 Immediate Outgoing interface list: Serial0/1/1, Forward, 00:00:31/00:02:58 Serial0/1/0, Forward, 00:06:10/00:00:19 Router B (debug ipv6 pim) Podobně jako u routeru A vidíme zprávu join root pro přidání zdroje do skupiny. Přes rozhraní serial 0/1/1 se dostaneme až k posluchači PC 2-4, který právě chce přijímat ze skupinové adresy FF7E:240:2001:2::5. *Jun 1 09:10:55.463: IPv6 PIM: J/P entry: Join root: 2001:E1::1 group: FF7E:240:2001:2::5 flags: S *Jun 1 09:10:55.463: IPv6 PIM: (2001:E1::1,FF7E:240:2001:2::5) Serial0/1/1 J/P state changed from Null to Join *Jun 1 09:10:55.463: IPv6 PIM: (2001:E1::1,FF7E:240:2001:2::5) Serial0/1/1 FWD state change from Prune to Forward *Jun 1 09:10:55.463: IPv6 PIM: (2001:E1::1,FF7E:240:2001:2::5) Updating J/P status from Null to Join Odebrání zdroje je vidět na následujícím výpisu: *Jun 1 09:11:20.483: IPv6 PIM: Sending J/P message for neighbor FE80::222:55FF:FEA2:3892 on Serial0/2/0 for 1 groups *Jun 1 09:11:40.011: IPv6 PIM: J/P entry: Prune root: 2001:E1::1 group: FF7E:240:2001:2::5 flags: S *Jun 1 09:11:40.011: IPv6 PIM: (2001:E1::1,FF7E:240:2001:2::5) Serial0/1/1 J/P state changed from Join to Null *Jun 1 09:11:40.011: IPv6 PIM: (2001:E1::1,FF7E:240:2001:2::5) Serial0/1/1 Imm FWD state change from Forward to Prune *Jun 1 09:11:40.011: IPv6 PIM: (*,FF7E:240:2001:2::5) Serial0/1/1 J/P state changed from Join to Null duben 2009 11/18

Router C (show ipv6 mroute) C#sh ipv6 mroute Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, I - Received Source Specific Host Report, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT Timers: Uptime/Expires Interface state: Interface, State Takto vypadá výpis, pokud stanice PC 2-4 přijímá skupinové vysílání. Můžeme vidět adresu RP 2001:2::2, rozhraní serial 0/1/0 na routeru C, na které přichází skupinová data a rozhraní fastethernet 0/0, kterým se data posílají stanici PC 2-4. Adresa 2001:E1::1 je adresou zdroje a FF7E:240:2001:2::5 skupinovou adresou obsahující adresu RP. Všimněme si také příznaku J, který znamená, že je posluchač součástí stromu. (*, FF7E:240:2001:2::5), 00:00:07/never, RP 2001:2::2, flags: SCJ Incoming interface: Serial0/1/0 RPF nbr: FE80::21E:BEFF:FEB4:ADE8 Immediate Outgoing interface list: FastEthernet0/0, Forward, 00:00:07/never (2001:E1::1, FF7E:240:2001:2::5), 00:00:07/00:03:22, flags: SJT Incoming interface: Serial0/1/0 RPF nbr: FE80::21E:BEFF:FEB4:ADE8 Inherited Outgoing interface list: FastEthernet0/0, Forward, 00:00:07/never Po ukončení příjmu stanice PC 2-4 se v seznamu odchozích rozhraní objeví null, příznak J je rozvněž zrušen. C#sh ipv6 mroute Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, I - Received Source Specific Host Report, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT Timers: Uptime/Expires Interface state: Interface, State (2001:E1::1, FF7E:240:2001:2::5), 00:01:59/00:01:30, flags: SP Incoming interface: Serial0/1/0 RPF nbr: FE80::21E:BEFF:FEB4:ADE8 Outgoing interface list: Null Router C (debug ipv6 mld) Začátek vysílání (přidání zdroje do stromu) je v mld výpisu zobrazen jako add new group s adresou přidané skupiny. *Jun 1 09:19:46.651: MLD: group_db: add new group FF7E:240:2001:2::5 on FastEthernet0/0 *Jun 1 09:19:46.651: MLD: MRIB updated (*,FF7E:240:2001:2::5) : Success *Jun 1 09:19:46.651: MLD: Switching to EXCLUDE mode for FF7E:240:2001:2::5 on FastEthernet0/0 duben 2009 12/18

Naopak zrušení vysílání (odebrání zdroje ze stromu) indikuje zpráva delete group, opět s danou skupinovou adresou. *Jun 1 09:20:32.323: MLD: group_db: delete group FF7E:240:2001:2::5 on FastEthernet0/0 Router G (show ipv6 mroute) Takto vypadá výpis, pokud stanice PC 3-2 přijímá skupinové vysílání. Můžeme vidět adresu RP 2001:2::2, rozhraní serial 0/1/0 na routeru G, na které přichází skupinová data a rozhraní fastethernet 0/0, kterým se data posílají stanici PC 2-4. Adresa 2001:E1::1 je adresou zdroje a FF7E:240:2001:2::5 skupinovou adresou obsahující adresu RP. Všimněme si také příznaku J, který znamená, že je posluchač součástí stromu. G#sh ipv6 mroute Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, I - Received Source Specific Host Report, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT Timers: Uptime/Expires Interface state: Interface, State (*, FF7E:240:2001:2::5), 00:00:07/never, RP 2001:2::2, flags: SCJ Incoming interface: Serial0/1/0 RPF nbr: FE80::21E:BEFF:FEB4:ADE8 Immediate Outgoing interface list: FastEthernet0/0, Forward, 00:00:07/never (2001:E1::1, FF7E:240:2001:2::5), 00:00:07/00:03:22, flags: SJT Incoming interface: Serial0/1/0 RPF nbr: FE80::21E:BEFF:FEB4:ADE8 Inherited Outgoing interface list: FastEthernet0/0, Forward, 00:00:07/never Další výpisy jsou podobné těm, které jsme získali na routeru C, proto je již neuvádíme. Router B (výpisy z programu Wireshark) V programu Wireshark jsme odchytávali zprávy ICMPv6, což jsou MLDv2 zprávy, které jsou popsány v teoretické části. Bližní popis jednotlivých zpráv je v části 7.4.5 pro PIM-SSM, protože stejné zprávy se posílají v obou režimech. Liší se pouze skupinová adresa. Na Obrázku 9 jsou vidět jednotlivé ICMPv6 zprávy, které jsme na routeru B zachytávali programem Wireshark. duben 2009 13/18

Obrázek 9: Výpis ICMPv6 zpráv z programu Wireshark 7.4 Výpisy z konzole (PIM-SSM) Výpisy z debugu jsou víceméně stejné jako u Sparse mode, liší se adresa skupiny a chybí adresa RP, protože u SSM se rendezvous point nepoužívá. Proto zde uvedeme pouze výpisy mroute. Router A (show ipv6 mroute) Vidíme, že mezi příznaky je malé s, které říká, že se jedná o PIM-SSM. Také samozřejmě chybí adresa RP. Adresa zdroje je 2001:E1::1, adresa skupiny FF33::DEAD. Skupinová data přicházejí na rozhraní fastethernet 0/0 a vystupují z rozhraní serial 0/1/0. A#sh ipv6 mroute Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, I - Received Source Specific Host Report, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT Timers: Uptime/Expires Interface state: Interface, State (2001:E1::1, FF33::DEAD), 00:11:36/00:02:52, flags: st Incoming interface: FastEthernet0/0 RPF nbr: 2001:E1::1 Immediate Outgoing interface list: Serial0/1/0, Forward, 00:11:36/00:02:52 duben 2009 14/18

Router B (show ipv6 mroute) Na routeru B je příchozím rozhraním serial 0/2/0, odchozí rozhraní má 2 (k routerům C a G) serial 0/1/1 a serial 0/1/0. B#sh ipv6 mroute Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, I - Received Source Specific Host Report, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT Timers: Uptime/Expires Interface state: Interface, State (2001:E1::1, FF33::DEAD), 00:14:24/00:02:53, flags: st Incoming interface: Serial0/2/0 RPF nbr: FE80::222:55FF:FEA2:3892 Immediate Outgoing interface list: Serial0/1/1, Forward, 00:02:57/00:02:34 Serial0/1/0, Forward, 00:12:33/00:02:53 Router C (show ipv6 mroute) Směrovače C a G jsou připojeny přímo k přijímacím stanicím, proto mají navíc příznak I. C#sh ipv6 mroute Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, I - Received Source Specific Host Report, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT Timers: Uptime/Expires Interface state: Interface, State (2001:E1::1, FF33::DEAD), 00:03:53/never, flags: sti Incoming interface: Serial0/1/0 RPF nbr: FE80::21E:BEFF:FEB4:ADE8 Immediate Outgoing interface list: FastEthernet0/0, Forward, 00:03:53/never Router G (show ipv6 mroute) G#sh ipv6 mroute Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, I - Received Source Specific Host Report, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT Timers: Uptime/Expires Interface state: Interface, State (2001:E1::1, FF33::DEAD), 00:03:37/never, flags: sti Incoming interface: Serial0/1/0 RPF nbr: FE80::21E:BEFF:FEB4:ADE8 Immediate Outgoing interface list: FastEthernet0/0, Forward, 00:03:37/never Router B (výpisy z programu Wireshark) Zprávu 143 (Report) posílá příjemce skupinových dat na adresu ff02::16 (adresa všech MLDv2 směrovačů na lince). Hlášení (report) obsahuje tzv. záznam, který nese skupinovou adresu a seznam duben 2009 15/18

zdrojů skupinových dat. V tomto případě vidíme typ záznamu Changed to include ff33::dead, tzn. že chceme tuto skupinu poslouchat. No. Time Source Destination Protocol Info 49638 7533.635523 fe80::216:76ff:fe69:1be ff02::16 ICMPv6 Multicast Listener Report Message v2 Internet Control Message Protocol v6 Type: 143 (Multicast Listener Report Message v2) Code: 0 (Should always be zero) Checksum: 0x18ef [correct] Changed to include: ff33::dead (ff33::dead) Mode: Changed to include Aux data len: 0 Multicast Address: ff33::dead Zprávu 130 (Query) na adresu skupiny posílá směrovač, ze které se nějaký posluchač odhlásil a chce tak vědět, zda existuje ještě nějaký posluchač této skupiny. Zdrojová adresa je adresou odesílatele skupinových dat. No. Time Source Destination Protocol Info 51881 7591.561839 fe80::21e:beff:feb4:a14a ff33::dead ICMPv6 Multicast listener query Internet Control Message Protocol v6 Type: 130 (Multicast listener query) Code: 0 Checksum: 0x3aee [correct] Maximum response delay[ms]: 1000 Multicast Address: ff33::dead S Flag: OFF Robustness: 2 QQI: 125 Source Address: 2001:e1::1 (2001:e1::1) Zprávu 130 (Query) na adresu ff02::1 (všechny uzly na lince) posílá směrovač opakovaně s nulovou skupinovou adresou. Důvod zasílání těchto zpráv je, že některé počítače přestanou poslouchat skupinu, aniž by to směrovači ohlásily. Ptá se tedy, které skupiny mají posluchače. No. Time Source Destination Protocol Info 51983 7657.793784 fe80::21e:beff:feb4:a14a ff02::1 ICMPv6 Internet Control Message Protocol v6 Type: 130 (Multicast listener query) Code: 0 Checksum: 0xf579 [correct] Maximum response delay[ms]: 10000 Multicast Address: :: S Flag: OFF Robustness: 2 QQI: 125 Zpráva 134 (Router advertisement) se posílá na všechny uzly na lince (adresa ff02::1) a slouží k bezstavové konfiguraci zařízení. V následujícím výpisu je vidět mnoho nastavení, která se touto zprávou posílají. No. Time Source Destination Protocol Info 51976 7624.490272 fe80::21e:beff:feb4:a14a ff02::1 ICMPv6 Router advertisement Internet Control Message Protocol v6 duben 2009 16/18

Type: 134 (Router advertisement) Code: 0 Checksum: 0x3b87 [correct] Cur hop limit: 64 Flags: 0x00 0...... = Not managed.0..... = Not other..0.... = Not Home Agent...0 0... = Router preference: Medium Router lifetime: 1800 Reachable time: 0 Retrans timer: 0 ICMPv6 Option (Source link-layer address) Type: Source link-layer address (1) Length: 8 Link-layer address: 00:1e:be:b4:a1:4a ICMPv6 Option (MTU) Type: MTU (5) Length: 8 MTU: 1500 ICMPv6 Option (Prefix information) Type: Prefix information (3) Length: 32 Prefix length: 64 Flags: 0xc0 1...... = Onlink.1..... = Auto..0.... = Not router address...0... = Not site prefix Valid lifetime: 2592000 Preferred lifetime: 604800 Prefix: 2001:e2:: 8 Závěr Multicastové vysílání v IPv6 je v mnohém podobné multicastu v IPv4. Mezi odlišnosti patří: jiný způsob mapování IP adres na MAC adresy protokol MLD namísto IGMP (zde se však jedná pouze o změnu názvu, funkce tohoto protokolu zůstala stejná možnost šíření adresy rendezvous pointu přímo v multicastové adrese Prakticky jsme ověřili funkčnost skupinového vysílání v režimu Sparse mode s embedded RP (tzn. s adresou rendezvous pointu obsaženou ve skupinové adrese) a v režimu PIM-SSM. Možnost režimu Dense mode se v IPv6 již nevyskytuje viz [5], popřípadě na http://www.cisco.com/en/us/tech/tk828/technologies_white_paper09186a0080203e90.shtml. Skupinové vysílání se v IPv6 zprovozní příkazem ipv6 multicast-routing, který je nutno zadat na každém routeru. Výchozím režimem je Sparse mode. Pro chod skupinového vysílání v režimu Sparse mode je potřeba určit místo, kde se setkávají zdroje a příjemci dat. Jednou z možností je nastavit adresu RP na každém routeru. Efektivnější je ovšem využití adresního prostoru IPv6 k tomu, abychom adresu RP propagovali přímo ve skupinové adrese a příjemci i zdroje z ní zjistí, kam mají data posílat. Jak jsme zjistili, nestačí pouze vytvořit skupinovou adresu podle adresy rozhraní routeru, který zvolíme jako RP. Je potřeba navíc vytvořit access list, který přiřadíme rendezvous pointu a povolíme jím ipv6 provoz na adresu skupiny. duben 2009 17/18

Skupinové vysílání v režimu PIM-SSM už rendezvous point nepoužívá žádosti počítačů o příjem skupinového vysílání se posílají přímo na adresu zdroje. Oproti Sparse mode se v PIM-SSM nepoužívá RP, proto zde nevidíme ani nastavení RP, ani skupinovou adresu, která by adresu RP obsahovala. Povolení SSM se provede příkazem ipv6 mld ssm-map enable. Pokud nemáme DNS server, musíme nastavit statické mapování příkazem ipv6 mld ssm-map static SSM 2001:E1::1, kde 2001:E1::1 je adresou zdroje. Stejně jako u Sparse mode s embedded RP musíme navíc přidat access list, který povolí ipv6 provoz na skupinovou adresu FF33::DEAD. 9 Použitá literatura [1] SATRAPA, Pavel. IPv6. Dokument dostupný na URL: http://knihy.nic.cz/ipv6 [2] P. SAVOLA, B. HABERMAN, Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address. Request for Comments: 3956 [3] Cisco Systems, Inc., IPv6 Multicast Configuration for Cisco IOS Software. Dokument dostupný na URL: http://www.cisco.com/en/us/tech/tk828/technologies_white_paper09186a0080203f7a.shtml [4] LHOTKA, Ladislav, SATRAPA Pavel, Networking Studies II, CESNET, z.s.p.o., 2008 [5] Ostling Janne, IPv6 for Dummies, Cisco Systems. Dokument dostupný na URL: http://ipv6forum.se/ wordpress/wp-content/uploads/2009/01/ipv6-for-dummies-se-090120.pdf duben 2009 18/18