Campus6

Contents

  1. IPv6 multicast áttekintése
    1. Bevezetés
      1. A mutlicast jelentősége (TriplePlay, IPTV, VoD, VPN)
        1. Miért kell tesztelni ?
        2. Mit kell tesztelni Triple Play-ben?
    2. IPv6 multicast alapvető müködése
      1. Miért jó a multicast?
      2. Multicast megvalósítás problémai
    3. IPv6 multicast címzés
    4. A mutlicast típusai (ASM, SSM)
    5. Multicast táblák
    6. A multicast csoportcímek kiválasztása (különböző stratégiák előnyei, hátrányai)
    7. A multicast csoportok meghirdetése
    8. Az IPv6 multicast megvalósítása
      1. Multicast csoporthoz tartozás menedzselése (MLD v1, v2)
      2. A multicast forgalomirányítás (alapok, PIM-SM, PIM-SSM)
    9. IPv6 multicast mintahálózatok (mbone, m6bone, 6net)
    10. IPv4 és IPv6 multicast hálózatok közötti átjárás (reflektor,gateway)
    11. Multicast alkalmazások (video, hang konferencia, menedzsment)
      1. Felhasználói alkalmazások
      2. Rendszergazdai/Monitoring alkalmazások
    12. Foglalt IPv6 multicast címek
    13. Referenciák

IPv6 multicast áttekintése

Bevezetés

Ez a dokumentáció meg probálja összefoglalni az IPv6 multicast tapasztalatainkat, amelyek hasznosak lehetnek egy Campus méretű rendszer tervezéséhez és üzemeltetéséhez. A dokumentáció további részében nem használjuk a többesküldést, mint a multicast magyar megfelelőjét, mert ez a terminólógia még nem terjedt el.

Az IPv6 multicast alapfogalmak, a működési típusok és a fejlesztést inspiráló alkalmazások rövid bemutatása után következik a két leglényegibb feladat a csoportok megszervezése és maga csomagtovábbítás megvalósítása. A zárórészben néhány IPv6 multicast megvalósítást ismertetünk, többnyire Campus méretűek, de a világméretű hálózatok sem az álmok kategóriájába tartoznak. Ennek csíráit már láthatjuk, a néhány világméretű tervvel és megvalósítással is találkozhatunk. Nem véletlenül került a végére az IPv4 multicast hálózatokkal levő kapcsolat kérdése. Nem szerettük volna a korlátozott IPv4 multicast megvalósításokkal kezdeni (bár nagyon sok kipróbált ötlet innen jön), mert az IPv6-ban mások a lehetőségek (alkalmasabb protokoll erre a feladatra), nem csak IPv4 továbbfejlesztések, hanem új protokollok tervezésére is sor került és még az alkalmazási történet elején vagyunk. A dokumentum végére kerültek a fejezethez tartozó rövidebb eredeti leírások, referenciák és ajánlások.

A mutlicast jelentősége (TriplePlay, IPTV, VoD, VPN)

Az informatika (számítástechnika) gyors fejlődése és alkalmazása a távközlésben (beágyazott rendszerekben) közel hozta egymáshoz a két területet (egy csatlakozó segítségével, egy hálózatból kapjuk a korábban több hálózattal biztosított szolgáltatásokat. A Triple Play egy hármas szolgáltatást takar: nagy sebességű internet, televízió (video on demand/kívánságra vagy hagyományosan sugárzott) és telefonszolgáltatás együttese egyetlen szélessávú kapcsolaton keresztül. Az átjárhatóság nem tervezési cél ugyan, de az IP mindegyik implementációban központi szerepet játszik.

A Triple Play lehet: {{{VoIP, IPTV, internet VoIP, VoD, VPN-kapcsolat IPTV, VoD, internet.}}}

A Triple Play architektúrája változatos, több fizikai közegen (a fizikai rétegben) lehet megvalósítani a kapcsolatot (rézvezeték, kábeltelevíziós koax, optika és drótnélkül).

Miért kell tesztelni ?

Nagyon fontos, hogy a különböző szolgáltatások minősége magas színvonalú legyen. Ez azt jelenti, hogy minden szolgáltatásnak biztosítani kell a jó minőségű (QoS, Quality of Service) működéshez a szükséges sávszélességet. Megnőtt az igény azon felügyelő és monitorozó rendszerek iránt, amelyekkel tesztelni is lehet (pl. NetSpotter iránt is).

Mit kell tesztelni Triple Play-ben?

Hiba lehet a hardver infrastruktúrában, a szolgáltatásban, az alkalmazásban, a QoS-ben, … . Így tehát egy sor vizsgálatra lehet szükség az ügyfél telephelyén, illetve a hozzáférési hálózatokon, pl.:

A fenti tesztek közöl mindegyikre szükségünk lehet, hogy jó minőségű legyen a szolgáltatás, a nagyvonalú specifikációt a következő táblázatban ismertetjük:

Adat

Voip

Steraming audió (Mp3)

Steraming videó (MPEG4)

Sávszélesség

Változó

12-106 kbit/s

32-320 kbit/s

0,005-10Mbit/s

Veszteség

Érzékeny

<1%

<2%

<2%

Késleltetés

Érzéketlen (ha interaktív használat esetén < 5s)

<250 ms

< 5s

< 5s

Jitter

Érzéketlen

< 25ms

Jitterpuffer

Jitterpuffer

IPv6 multicast alapvető müködése

Az IPv6 három adattovábbítási formát támogat az adó(k) és vevő(k), mint interfészek között. Az unicast továbbítás esetén az adatokat eljuttatjuk az egyedi, individuális címmel ellátott vevőhöz. A multicast csoportos szállítást jelent, az adatokat el kell juttatni a csoport minden tagjához. A anycast továbbítás szintén egy jól meghatározott csoporttal kapcsolatos, ekkor a csoport egy (valamilyen módon egyértelműen meghatározott, legközelebbi) tagjának továbbítjuk az adatot. Az anycast továbbításban résztvevők címei megegyeznek az unicast továbbításban használatos címtartománnyal. Az üzenetszórás (broadcast) az IPv6-ban nem használatos, ez a multicast egy speciális esetének tekinthető.

Miért jó a multicast?

A multicast alkalmazása számottevően csökkenti az adathálózat terhelését, a multimédiás konferenciázás esetén és az információ szétosztásánál rendkívül hatékony. Az adatokat egy példányban tudjuk eljuttatni egy vagy több felhasználónak. A multicast akkor hasznos, amikor a forrásállomás több címzettnek is szeretné elküldeni ugyanazt a csomagot. Ilyen esetben az egyedi küldés nagyon kis hatékonyságú.

Multicast megvalósítás problémai

A gyakorlati megvalósításnál számtalan elvi probléma felmerül, a számítógép-hálózati architektúra második (L2) és harmadik (L3) rétege érintett:

IPv6 multicast címzés

Mielőtt az IPv6 multicast típusait bemutatjuk, nézzük meg az IPv6 16 bájtos címzését, amely a multicasttal kapcsolatos. A típusok a multicast címzés által is meghatározottak. A mutlicast csoportok címében a 128 bit hosszú címmező első 8 bitje csupa 1-es (ff00::/8). A következő 4 bit a jelző biteket tartalmazó bitmező. Ezt követi újabb 4 bites mező, amely az adatszórás tartományát azaz scope-ját határozza meg. A maradék 112 bitet használjuk a csoportok címzésére (még ebben is van néhány foglalt, előre definiált cím, amely speciális jelentéssel bíró csoportot jelöl).

A 4 darab jelzőbit: 

                       0RPT      T = 0 állandó (permanens) cím
                                 T = 1 időleges (temporális) cím
                                 P = 1 egyedi címmel kombinált (unicast prefix)
                                 R = 1 randevú pont (RP) címének beágyazása.

Az adatszórási tartom'nz 4-es bitcsoportjának néhány jellemző hexadecimális értéke : 

        1 =  a csomópont saját maga (node, loopback)
        2 =  helyi kapcsolat (link-local), fizikai réteg interfésze (soros vonal, Ethernet)
        5 =  helyi kiszolgáló (helyen, site-local)
        8 =  helyi szervezet (organization-local)
        e =  globális, az egész internet.

Előre definiált statikus címek (T = 0 a jelzőrészben, a 12-edik bit 0): 

        ff01::1  az összes csomópont az adott interfészen
        ff02::1  az összes csomópont az adott linken
        ff01::2  az összes útvonalválasztó az adott interfészen
        ff02::2  az összes  útvonalválasztó az adott linken
        ff05::2  az összes  útvonalválasztó az adott kiszolgálón (helyen)
        ff01::101  az összes NTP szerver az adott interfészen
        ff02::101  az összes NTP szerver az adott linken
        ff0e::101  az összes NTP szerver az egész Interneten.

További elődefiniált multicast címcsoport a szomszédok keresésénél használt solicited-node címét határozza meg, az utolsó 24 biten a csomópont egyedi vagy szelektív címe helyezkedik el: 

        ff02:0:0:0:0:1:ff00:0/104

Ideiglenes (transient) címek (T = 1 a jelzőrészben): 

ff1::groupid32/128

ff3s:prefixlength:prefix64:groupid32

ff7s:rRpl:RPprefix64:groupid32

ff3s:allzeros80:groupid32

A mutlicast címek változatainak, a foglalt címek aktuális listáját a Assigned IPv6 Multicast címen találhatjuk meg.

A mutlicast típusai (ASM, SSM)

Két multicast típust mutatunk be:

  1. Tetszőleges forrású mutlicast(Any-Source Multicast, ASM). Ez a klasszikusnak mondható típus, az IP csomagot el kell juttatni a vevők csoportjához. Itt megengedett a több forrás is (nemcsak az egy-a-többes, hanem a több-a-többes kommunikáció). A forrásnak nem kell a csoporthoz tartoznia, a vevő hosztok bármikor csatlakozhatnak a csoporthoz és bármikor ki is jelentkezhetnek. A csoport adminisztrálási feladatokat a routerek az MLD v1 (Multicast Listener Discovery) protokollal tudják végrehajtani.
  2. Forrás specifikus multicast (SSource-Specific Multicast, SSM). A csoport hosztjai meg tudják határozni, hogy csak mely forrásoktól (only), vagy mely forrásoktól nem (all except) fogadnak el IP csomagokat. A szűrést az MLD v2 protokoll segítségével tudjuk beállítani.

Multicast táblák

A címzés és a típusok után három adminisztrációs tábla (adatbázist) bemutatása is az alapkoncepcióhoz tartozik:

  1. Az MRIB (Multicast Information Base) tábla a forrás állomás helyének megállapítását és RFP (Reverse Path Forwarding) útképzéssel való leellenőrzését támogatja.
  2. A TIB (Tree Information Base) tábla állapotinformációkat tartalmaz, amelyeket az útképző és csoport kommunikációt végrehajtó protokollok állítanak be (PIM, MLD).
  3. Az MFIB (Multicast Forwarding Information Base) tábla kizárólag a továbbítás irányával foglalkozik, az MRIB és TIB információiból épül fel.

A multicast útvonal meghatározása egy fa struktúra felépítését jelenti. Több protokoll együttműködéséből keletkezik ez a fa. A felhasználókkal az MLD (Multicast Listener Protocol) kommunikál, a résztvevők jelentik a fa leveleit (küldő, fogadó). A fa elágazási pontjai az adathálózati csomópontok (routerek) és az ezek közötti forgalmat a PIM (Protocol Independent Multicast) portokoll bonyolítja le.

A multicast csoportcímek kiválasztása (különböző stratégiák előnyei, hátrányai)

A multicast címek megadásánál jó lenne bizonyos értelemben globálisan egyedi címeket megadni. Így elkerülhetőek a címütközések. Az SSM típusban (modellben) nem fordul elő, hogy a küldőnek két azonos című csoportnak kelljen küldeni. Az ASM típus esetén nemcsak a cím-ütközés elkerülése a fontos, hanem a port-ütközésé is.

Az általános multicast címstruktúrát már ismertettük az előzőekben, itt csak a rövid összefoglalást tesszük meg: 

        ff0x::/16       állandó (fix) multicast cím
        ff1x::/16       ideiglenes multicast cím
        ff3x::/16       unicast alapú ideiglenes multicast cím
        ff3x::/96       SSM típusú multicast cím
        ff7x::/16       beágyazott RP típusú ideiglenes multicast cím

A számos multicast címkiosztási módszerből hetet említünk meg:

  1. Csak az általános útmutatás szerint osztunk címeket, a teljes címtérből választhatunk.
  2. Véletlenszerű (random) választást biztosító algoritmussal osztunk címeket,
    • akkor csináljuk ezt, ha nincs ennél jobb módszerünk.
  3. SAP mehanizmus, a SAP kihirdeti a címkiválasztást.
  4. MADCAP egy kliens-szerver architektúra, amelz támogatja az IPv6 és IPv4 címkiosztást is.
  5. DHCPv6 hasonló a DHCPv4 és MADCAP-hez, kiemelhető az IA (Identify Association) kommukáción kívül a kliens kreatív szerepe.
  6. ZMAAP, egy mini-MAAS szerver osztja a címeket. A SAP és a ZMAAP kis számú címet igénylő esetekben alkalmazható.
  7. Az absztrakt API egy paraméterekkel ellátott kérés a címkiosztó rendszer felé.

A kiosztott címeket megtalálhatjuk a SAP, Web, e-mail, és DNS rendszerekben.

A multicast csoportok meghirdetése

Az elérhető szolgáltatások megtekintésére (session announcement) három katalógus eszköz áll rendelkezésre, amelyeken kívül természetesen használhatjuk azt az egyszerű módszert, hogy valamilyen egyéb csatornán (pl. e-mail) meghírdetjük a a multicast csoportot.

  1. SDR (Session Directory Tool) az Mbone hálozaton a multicast konferenciákat adminisztrálja
  2. SCS (Secure Conference Store) rendszer egy web alapú konfrencia menedzselő rendszer az UCL-en fejlesztették ki
  3. LDAP-ban tároljuk az SDP üléseket.

Összefoglalásként ismertetjük a különböző metodikáknak kijelölt intervallumokat: 

0x80000000 – 0x8fffffff MADCAP
0x90000000 – 0x9fffffff DHCPv6
0xa0000000 – 0xafffffff Véletlenszerű (Random)
0xb0000000 – 0x8bffffff ZMAAP
0xc0000000 – 0xffffffff nem használt.

Az IPv6 multicast megvalósítása

Az IPv6 multicast csoport a vevők egy tetszőleges csoportja, akik egy kiválasztott adatfolyamot szeretnének venni. A csoport elhelyezkedésének nincsenek fizikai és földrajzi korlátai. A vevőknek csatlakozniuk kell az adott csoporthoz, ezt a csatlakoztatást végzi az MLD protokoll - a legközelebbi routeren.

Az útvonalválasztók szintén az MLD protokollt használják, hogy megtudják vajon vannak-e csoport-tagok a hozzájuk tartozó alhálózatokban. Azután az adathálózaton a potenciálisan korlátlan számú vevő felé az adat alhálózatonként egy példányban továbbítódik.

A korábbiakban tárgyaltuk a címkiosztás megoldásait. A csoporthoz való tartozás dinamikus, bármikor fel és le tudunk jelentkezni a csoportbeli listákról. Egy munkaállomás, vevő (host) több csoportohoz is tartozhat. A csoportok működése nem kell , hogy folyamatos aktivitást jelentsen. Lehet olyan csoport, amelynek vannak tagjai, de a csoport nem aktív.

Az útképzés megvalósításához szükségesek a szintén korábban említett adatbázisok (MRIB, TIB és MFIB). Az útképzés egy útvonalat jelentő fa felépítése. Ezt az adathálózati oldalon a PIM (Protocol Indpendent Protocol) végzi, a felhasználói, vevői oldalom az MLD (Multicast Listener Discovery) protokoll kommunikál a vevőkkel. Erről a két protokollról ismertetünk további informácikat a következőkben.

Multicast csoporthoz tartozás menedzselése (MLD v1, v2)

MLD protokollt használnak a routerek, hogy felfedezzék a direkt kapcsolataikon a multicast használó vevőket és felfedezzék, hogy milyen muulticast címek találhatók a szomszédos csomópontokban. Az MLD automatikusan vezérli és limitálja a multicast forgalmat a multicast lekérdezők (queriers) és a végpontok (vevők, hostok) segítségével. A lekérdező az, aki kérdő üzeneteket küld ki, hogy felfedezze kik az adott csoport tagjai. A végpont az, aki riportot küld a kérdezőnek a csoportbeli tagságról. A lekérdezők és végpontok, akik ugyanattól a forrástól veszik az adatokat egy multicast csoportot alkotnak. A lekérdezők és végpontok MLD riportokat generálnak a csatlakozáshoz és a csoport elhagyásához is.

Az MLD ICMPv6 (Internet Control Message Protocol) protokollt használ az üzeneteinek a továbbítására. Minden MLD üzenet link-local 1-es ugrásszámmal (hop limit 1) és mindegyik csomóponti (router) riasztási opcióval ellátott, hogy minden csomópont végrehajtsa az opcionális fejlécben meghatározott feladatokat. Ebben a fejlécben háromféle üzenet van:

Az MLD riportban érvényes link-lokál cím vagy nemspecifikált cím van (ez utóbbi eset csak akkor, ha NDP/Neighbour Discovery Protokol szomszédokat felderító protokoll használata engedélyezett). Több multicast cím fogadása (DAD, Duplicate Address Detection) esetén kötelező a nemspecifikált cím használata az egy igazi interfész-címen kívül a többi cím nemspecifikált lesz. Az MLDv2 támogatja a forrás szűrését (SSM). A csoport elhagyása kb. 2 másodpercet vesz igénybe.

A multicast forgalomirányítás (alapok, PIM-SM, PIM-SSM)

A PIM egy hatékony IPv4 és IPv6 útképzési protokoll, amely független mindenféle egyedi útképző táblától az RPF (Reverse Path Forwarding) saját fordított útvonalának a végrehajtásánál. Az IPv6 multicast esetében a PIM-SM vagy a PIM_SSM működésmód a használatos (a kettő együtt is alkalmazható).

PIM-SM (Sparse Mode) azaz ritka mód, amely azt jelenti, hogy kevés számú útvonalválasztó érintett és ezeket is a lekérdezésekkel direkt módon kell bekapcsolni a forgalomba. Az adatkérési csatlakozás áthalad a csomópontokon (PIM join) a győkér csomóponthoz (RP, Rendezvous Point vagy SPT, Shortest Path Tree-nél a forrás felőli első útvonalválsztó, first-hop router). A leiratkozás, megszüntetés (PIM prune) üzenet felszámolja a csoportot és a forrást is.

A PIM-SM alapvető fogalmai közé tartozik a megjelölt útvonalválasztó (DR, Designated Router), amelynek a feladata a PIM üzenetek (join, prune, register) továbbíttása az RP felé egy adott LAN-ból. Ha több erre alkalmas útvonalválasztó van, akkor egyszerű szavazással dől el az egyedi DR-kérdés, a nagyobb IPv6-os című lesz a DR.

Az RP kihirdetése három módon történhet:

Az RP által meghatározott Osztott fa (Shared Tree) kilenc lépésben átalakítható esetlegesen optimálisabb fává. Ez lesz a Forrás fa (Source Tree vagy Shortest Path Tree), amely hatékonyabb csomagtovábbítást tesz lehetővé.

PIM-SSM (Source Specific Multicast) csak a forrás és csoport párra vonatkozó eljárásokat tartalmaz (S, G, Source, Group). A vevő oldalon a már említett MLDv2, a hálózati oldalon az SSM megvalósítás (PIM join-ek továbbítása az RPF (Reverse Path Forwarding) szerint) eredményezi a hatékony működést.

Az SSM jó nemcsak a tartományokon belüli (intra domain), de a tartományok közötti (inter domain) mutlicastra.

A téma iránt mélyebben érdeklődőknek ajánljuk nemcsak a harmadik rétegben (data network) használatos, jól ismert protokollok multicast módosításait (MRoute, MOSPF, MBGP, PIM-SM, PIM-DM, PIM-SSM, BIDIR), hanem a második rétegben (LAN, lokális hálózatokban, data link-ben) megvalósított protokollokat (IGMP, CGMP, GARP).

IPv6 multicast mintahálózatok (mbone, m6bone, 6net)

A sikeres 6net projekt eredményeinek egyik egyre erősödő szelete a mutlicast. Az első minta hálózat 10 évvel ezelőtt, 1996 már működött. A már említett IPTV alkalmazás egyre gyorsabb elterjedése előbb az IPv4-ben erősíti a gyakorlati megvalósítást. Talán az eddigiekből is kitűnhet, hogy az alkalmazások IPv4-ből történő átvitele nem túl bonyolult (természetesen az IPv6 alapinfrastruktúra megteremtése után). Az Interneten ezek a rendszerek saját, részletes beszámolókat tartalmazó honlapokon ismertetik fejlesztési terveiket és tapasztalataikat.

IPv4 és IPv6 multicast hálózatok közötti átjárás (reflektor,gateway)

Ebben a résztémában talán a M6Bone projekt ért el szép eredményeket. Elkészültek azok az eljárások, amelyek a multicast szolgáltatást olyan vevőknek is biztosítják, akik nem az eddig említett eljárások szerint tudnak kapcsolódni a hálózathoz.

A M6Bone honlapján az alkalmazások között három kiterjesztést találhatunk:

Multicast alkalmazások (video, hang konferencia, menedzsment)

A dokumentum további részében nagyon röviden felsoroljuk az átlagos felhasználók lehetőségeit a multicaston alapuló szolgáltatások igénybevételére. A munkaszakaszban megvizsgáltuk a más, nem LAN adathálózati kapcsolódás esetén felmerülő lehetőségeket, korlátokat és a fejllesztés várható irányait. Ha megnézzük mégegyszer a Triple Play táblázatát, akkor a gyorsan fejlődő xDSL szolgáltatás már alkalmas lesz ilyen szolgáltatások használatára. A kapcsolt telefon-modemes kapcsolat is korlátozottan alkalmazható.

Felhasználói alkalmazások

Rendszergazdai/Monitoring alkalmazások

Foglalt IPv6 multicast címek

INTERNET PROTOCOL VERSION 6 MULTICAST ADDRESSES
(last updated 2006-08-17)
IPv6 multicast addresses are defined in "IP Version 6 Addressing
Architecture" [RFC4291].  This defines fixed scope and variable scope
multicast addresses.
IPv6 multicast addresses are distinguished from unicast addresses by the
value of the high-order octet of the addresses: a value of 0xFF (binary
11111111) identifies an address as a multicast address; any other value
identifies an address as a unicast address.
The rules for assigning new IPv6 multicast addresses are defined in
[RFC3307].   IPv6 multicast addresses not listed below are reserved.
Current IPv6 multicast addresses are listed below.

Fixed Scope Multicast Addresses
-------------------------------
These permanently assigned multicast addresses are valid over a specified
scope value.

 Node-Local Scope
 ----------------
   FF01:0:0:0:0:0:0:1     All Nodes Address                  [RFC4291]
   FF01:0:0:0:0:0:0:2     All Routers Address                [RFC4291]
   FF01:0:0:0:0:0:0:FB    mDNSv6                             [Cheshire]

 Link-Local Scope
 ----------------
   FF02:0:0:0:0:0:0:1     All Nodes Address                  [RFC4291]
   FF02:0:0:0:0:0:0:2     All Routers Address                [RFC4291]
   FF02:0:0:0:0:0:0:3     Unassigned                         [JBP]
   FF02:0:0:0:0:0:0:4     DVMRP Routers                      [RFC1075,JBP]
   FF02:0:0:0:0:0:0:5     OSPFIGP                            [RFC2328,Moy]
   FF02:0:0:0:0:0:0:6     OSPFIGP Designated Routers         [RFC2328,Moy]
   FF02:0:0:0:0:0:0:7     ST Routers                         [RFC1190,KS14]
   FF02:0:0:0:0:0:0:8     ST Hosts                           [RFC1190,KS14]
   FF02:0:0:0:0:0:0:9     RIP Routers                        [RFC2080]
   FF02:0:0:0:0:0:0:A     EIGRP Routers                      [Farinacci]
   FF02:0:0:0:0:0:0:B     Mobile-Agents                      [Bill Simpson]
   FF02:0:0:0:0:0:0:C     SSDP                               [Kostic]
   FF02:0:0:0:0:0:0:D     All PIM Routers                    [Farinacci]
   FF02:0:0:0:0:0:0:E     RSVP-ENCAPSULATION                 [Braden]
   FF02:0:0:0:0:0:0:F     UPnP                               [Fairman]
   FF02:0:0:0:0:0:0:16    All MLDv2-capable routers          [RFC3810]
   FF02:0:0:0:0:0:0:6A    All-Snoopers                       [RFC4286]
   FF02:0:0:0:0:0:0:FB    mDNSv6                             [Cheshire]
   FF02:0:0:0:0:0:1:1     Link Name                          [Harrington]
   FF02:0:0:0:0:0:1:2     All-dhcp-agents                    [RFC3315]
   FF02:0:0:0:0:0:1:3     Link-local Multicast Name Resolu   [Aboba]
   FF02:0:0:0:0:0:1:4     DTCP Announcement                  [Vieth,Terst.]
   FF02:0:0:0:0:1:FFXX:XXXX     Solicited-Node Address       [RFC4291]
   FF02:0:0:0:0:2:FF00::/104    Node Information Queries     [RFC4620]

 Site-Local Scope
 ----------------
   FF05:0:0:0:0:0:0:2       All Routers Address              [RFC4291]
   FF05:0:0:0:0:0:0:FB      mDNSv6                           [Cheshire]
   FF05:0:0:0:0:0:1:3       All-dhcp-servers                 [RFC3315]
   FF05:0:0:0:0:0:1:4       Deprecated (2003-03-12)
   FF0X:0:0:0:0:0:1:1000    Service Location, Version 2      [RFC3111]
    -FF0X:0:0:0:0:0:1:13FF

Variable Scope Multicast Addresses
----------------------------------

These permanently assigned multicast addresses are valid over all scope
ranges.  This is shown by an "X" in the scope field of the address that
means any legal scope value.
Note that, as defined in [RFC4291], IPv6 multicast addresses which
are only different in scope represent different groups.  Nodes must
join each group individually.

The IPv6 multicast addresses with variable scope are listed below.

   FF0X:0:0:0:0:0:0:0     Reserved Multicast Address         [RFC4291]
   FF0X:0:0:0:0:0:0:C     SSDP                               [Kostic]
   FF0X:0:0:0:0:0:0:FB    mDNSv6                             [Cheshire]
   FF0X:0:0:0:0:0:0:100   VMTP Managers Group                [RFC1045,DRC3]
   FF0X:0:0:0:0:0:0:101   Network Time Protocol (NTP)        [RFC1119,DLM1]
   FF0X:0:0:0:0:0:0:102   SGI-Dogfight                       [AXC]
   FF0X:0:0:0:0:0:0:103   Rwhod                              [SXD]
   FF0X:0:0:0:0:0:0:104   VNP                                [DRC3]
   FF0X:0:0:0:0:0:0:105   Artificial Horizons - Aviator      [BXF]
   FF0X:0:0:0:0:0:0:106   NSS - Name Service Server          [BXS2]
   FF0X:0:0:0:0:0:0:107   AUDIONEWS - Audio News Multicast   [MXF2]
   FF0X:0:0:0:0:0:0:108   SUN NIS+ Information Service       [CXM3]
   FF0X:0:0:0:0:0:0:109   MTP Multicast Transport Protocol   [SXA]
   FF0X:0:0:0:0:0:0:10A   IETF-1-LOW-AUDIO                   [SC3]
   FF0X:0:0:0:0:0:0:10B   IETF-1-AUDIO                       [SC3]
   FF0X:0:0:0:0:0:0:10C   IETF-1-VIDEO                       [SC3]
   FF0X:0:0:0:0:0:0:10D   IETF-2-LOW-AUDIO                   [SC3]
   FF0X:0:0:0:0:0:0:10E   IETF-2-AUDIO                       [SC3]
   FF0X:0:0:0:0:0:0:10F   IETF-2-VIDEO                       [SC3]
   FF0X:0:0:0:0:0:0:110   MUSIC-SERVICE                      [G van Rossum]
   FF0X:0:0:0:0:0:0:111   SEANET-TELEMETRY                  [Andrew Maffei]
   FF0X:0:0:0:0:0:0:112   SEANET-IMAGE                      [Andrew Maffei]
   FF0X:0:0:0:0:0:0:113   MLOADD                             [Braden]
   FF0X:0:0:0:0:0:0:114   any private experiment             [JBP]
   FF0X:0:0:0:0:0:0:115   DVMRP on MOSPF                     [Moy]
   FF0X:0:0:0:0:0:0:116   SVRLOC                             [Guttman]
   FF0X:0:0:0:0:0:0:117   XINGTV                          <hgxing@aol.com>
   FF0X:0:0:0:0:0:0:118   microsoft-ds              <arnoldm@microsoft.com>
   FF0X:0:0:0:0:0:0:119   nbc-pro                <bloomer@birch.crd.ge.com>
   FF0X:0:0:0:0:0:0:11A   nbc-pfn                <bloomer@birch.crd.ge.com>
   FF0X:0:0:0:0:0:0:11B   lmsc-calren-1                      [Uang]
   FF0X:0:0:0:0:0:0:11C   lmsc-calren-2                      [Uang]
   FF0X:0:0:0:0:0:0:11D   lmsc-calren-3                      [Uang]
   FF0X:0:0:0:0:0:0:11E   lmsc-calren-4                      [Uang]
   FF0X:0:0:0:0:0:0:11F   ampr-info                          [Janssen]
   FF0X:0:0:0:0:0:0:120   mtrace                             [Casner]
   FF0X:0:0:0:0:0:0:121   RSVP-encap-1                       [Braden]
   FF0X:0:0:0:0:0:0:122   RSVP-encap-2                       [Braden]
   FF0X:0:0:0:0:0:0:123   SVRLOC-DA                          [Guttman]
   FF0X:0:0:0:0:0:0:124   rln-server                         [Kean]
   FF0X:0:0:0:0:0:0:125   proshare-mc                        [Lewis]
   FF0X:0:0:0:0:0:0:126   dantz                              [Yackle]
   FF0X:0:0:0:0:0:0:127   cisco-rp-announce                  [Farinacci]
   FF0X:0:0:0:0:0:0:128   cisco-rp-discovery                 [Farinacci]
   FF0X:0:0:0:0:0:0:129   gatekeeper                         [Toga]
   FF0X:0:0:0:0:0:0:12A   iberiagames                        [Marocho]
   FF0X:0:0:0:0:0:0:12B   X Display                          [McKernan]
   FF0X:0:0:0:0:0:0:12C   oap-multicast                      [Eastham]
   FF0X:0:0:0:0:0:0:12D   DvbServDisc                        [Willigen]
   FF0X:0:0:0:0:0:0:12E   Ricoh-device-ctrl                  [Ohhira]
   FF0X:0:0:0:0:0:0:12F   Ricoh-device-ctrl                  [Ohhira]
   FF0X:0:0:0:0:0:0:201  "rwho" Group (BSD) (unofficial)     [JBP]
   FF0X:0:0:0:0:0:0:202   SUN RPC PMAPPROC_CALLIT            [BXE1]
   FF0X:0:0:0:0:0:0:300   Mbus/Ipv6                          [RFC3259]
   FF0X:0:0:0:0:0:2:0000
    -FF0X:0:0:0:0:0:2:7FFD  Multimedia Conference Calls      [SC3]
   FF0X:0:0:0:0:0:2:7FFE    SAPv1 Announcements              [SC3]
   FF0X:0:0:0:0:0:2:7FFF    SAPv0 Announcements (deprecated) [SC3]
   FF0X:0:0:0:0:0:2:8000
    -FF0X:0:0:0:0:0:2:FFFF  SAP Dynamic Assignments          [SC3]

FF3X:0::0-FF3X:0000:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF (FF3X:0000:/32) Source-Specific Multicast block
Registration Rules:
Addresses in FF3X:0000:/32 but not listed below are reserved for future SSM
address use, but are currently invalid.
FF3X::4000:1-FF3X::7FFF:FFFF - IETF consensus
FF3X::8000:0-FF3X::FFFF:FFFF - Dynamically allocated by hosts when needed [RFC-ietf-ssm-arch-07.txt].

Address/Range                Description                         Reference
---------------------------  ----------------------------------  ---------
FF3X::0:0-FF3X::3FFF:FFFF    Invalid addresses                   [RFC-07.t]
FF3X::4000:0                 Reserved                            [RFC-07.t]
FF3X::4000:1-FF3X::7FFF:FFFF Reserved for IANA allocation        [RFC-07.t]
FF3X::8000:0-FF3X::FFFF:FFFF Reserved for local host allocation  [RFC-ietf-ssm-arch-07.txt]

Referenciák

Campus6: ipv6multicast (last edited 2008-04-10 15:29:37 by localhost)