Speci€ln• IP adresy Někter• IP adresy jsou vyhrazeny pro speci‚lnƒ „čely: Rozsah od 224.0.0.0 do 239.255.255.255 je zařazen do třƒdy D. Tato třƒda je využƒv‚na pro multicasting. To znamen‚ pro hromadn• vysƒl‚nƒ videa nebo audia. Rozsah od 240.0.0.0 do 247.255.255.255 patřƒ do třƒdy E. Tyto hodnoty jsou rezervov‚ny pro dalšƒ použitƒ a pro experiment‚lnƒ „čely. 127.0.0.0 nebo 127.0.0.1 jsou určeny k testovacƒm „čelům. NazŠvajƒ se loopback adresy. Tyto adresy použƒv‚ sƒťovŠ software. Pošleme-li data na tuto adresu, nebudou vysƒl‚na přes ž‚dnŠ ze sƒťovŠch adapt•rů počƒtače do sƒtě. Pouze zjistƒme zda je funkčnƒ software, nez‚visle na tom, funguje-li sƒťovŠ hardware. S•ťovƒ adresy, tj. adresy, jejichž host č‚st obsahuje sam• nuly. Tyto adresy jsou využƒv‚ny IP protokolem ke spr‚vn•mu směrov‚nƒ paketů mezi sƒtěmi. Broadcast adresa, 255.255.255.255 je určena všem hostům v dan• sƒti. Použƒvajƒ se k hromadn•mu rozesƒl‚nƒ paketů. Intranet, pokud je sƒť izolovan‚, bez připojenƒ k Internetu, lze použƒt libovoln• IP adresy. Při připojenƒ vnitřnƒ sƒtě k Internetu by ale mohla nastat situace že budou existovat dvě stejn• IP adresy. T•to skutečnosti zabraňuje PROXY br‚na. Proxy br‚na může sloužit pro libovolnou službu protokolu TCP/IP. Proxy je ve skutečnosti počƒtač, kterŠ je připojen libovolnŠm způsobem k Internetu. Musƒ mƒt skutečnou IP adresu aby viděl "ven" a z "venku" byl vidět. Při naps‚nƒ nějak• www adresy na počƒtači ve vnitřnƒ sƒti, prohlƒžeč odešle tento dotaz na proxy br‚nu. Ta se dot‚že svŠm jm•nem na Internetu a pot• před‚ požadavek zp‚tky počƒtači. A na okolnƒch počƒtačƒch se nastavƒ adresa vyhrazen‚ pro vnitřnƒ sƒtě. Rezervovan• IP pro vnitřnƒ sƒtě: Tř•da A : 10.0.0.0 až 10.255.255.255 Tř•da B : 172.16.0.0 až 172.31.0.0 Tř•da C : 192.168.0.0 až 192.168.255.0
Multicast IP adresy Multicast adresnƒ rozsahy:
224.0.0.0 až 224.0.0.255 - určen• pro sƒťov• protokoly uvnitř LAN, majƒ TTL = 1, takže nepřejdou přes router 224.0.1.0 až 238.255.255.255 - jsou glob‚lnƒ multicast adresy, kter• se použƒvajƒ mezi organizacemi a přes internet 239.0.0.0 až 239.255.255.255 - je omezenŠ rozsah adres, pro použitƒ uvnitř organizace (LAN)
Někter• speci‚lnƒ adresy:
224.0.0.1 - skupina všech stanic připojenŠch k lok‚lnƒ podsƒti, 224.0.0.2 - skupina všech směrovačů připojenŠch k lok‚lnƒ podsƒti, 224.0.0.5 - skupina všech směrovačů podporujƒcƒch směrovacƒ protokol OSPF 224.0.0.6 - skupina všech jmenovanŠch směrovačů podporujƒcƒch protokol OSPF.
VLSM Původně se předpokl‚dalo, že možnost podsƒťov‚nƒ bude dostatečnou podporou využitƒ adresov•ho prostoru. Proto se v r‚mci jedn• IP sƒtě použƒvala jedna podsƒťov‚ maska, tzn. všechny podsƒtě využƒvaly stejn•ho počtu bitů pro svoje adresy. Nicm•ně tato situace nevyhovovala v přƒpadě, kdy byl požadavek na počet podsƒtƒ značnŠ (na z‚kladě počtu fyzickŠch segmentů) a segmenty navƒc připojovaly velmi odlišnŠ počet stanic. Zatƒmco s•riov• spoje mohou propojovat pouze dva uzly, takže potřebujƒ adresovŠ prostor v r‚mci podsƒtě pouze pro dvě adresy stanic, tak lok‚lnƒ sƒť Ethernet může propojovat stovky stanic a jejƒ požadavky na adresovŠ prostor stanic jsou podstatně vyššƒ. Tomuto požadavku se vyhovělo možnostƒ použƒvat v r‚mci jedn• adresy sƒtě několika podsƒťovŠch masek různ• d•lky (Variable Length Subnet Masks, VLSM; RFC 1812) odpovƒdajƒcƒch konkr•tnƒm požadavkům na adresaci podsƒtƒ a připojenŠch stanic. VŠsledn• adresy stanic musƒ bŠt nad‚le jednoznačn•. VLSM umožňuje podsƒťovat podsƒtě, jinŠmi slovy vyjƒt z adresy podsƒtě a tu d‚le dělit podle stejnŠch pravidel, jak‚ byla uvedena vŠše. VŠsledkem VLSM je, že mƒsto velk•ho počtu stanic, jejichž počet by se prakticky zdaleka nevyužil, se dalšƒm podsƒťov‚nƒm zƒsk‚ daleko vƒce podsƒtƒ a v každ• z nich lze vymezit rozsah použitŠch adres 2x – 2, kde x je počet bitů potřebnŠch pro adresov‚nƒ podsƒtě.
CIDR V devades‚tŠch letech se způsob adresov‚nƒ v IP změnil tak, že se přestalo dodržovat přidělov‚nƒ adres podle hierarchie třƒd, ale umožnilo se použƒt prefix libovoln• d•lky. Beztřƒdnƒ adresov‚nƒ, adresov‚nƒ bez ohledu na třƒdy, umožnilo kompletnějšƒ využitƒ adresov•ho prostoru omezen•ho 32 bity. Předevšƒm z hlediska směrov•n‚ v souvislosti s růstem Internetu se zjistilo, že je nevhodn• budovat směrovacƒ tabulky na z‚kladě IP adres různŠch třƒd, tedy agregace adres pro zmenšenƒ počtu z‚znamů ve směrovacƒ tabulce na hranici adres sƒtƒ. Proto se přešlo od směrov‚nƒ na z‚kladě třƒd adres ke směrov‚nƒ na z‚kladě prefixu adres (Classless Inter-Domain Routƒng, CIDR), kter• umožňuje agregovat adresy pro směrov‚nƒ v sƒti na z‚kladě společn•ho prefixu adresy bez ohledu na třƒdu adres. CIDR (RFC 4632) se tak• někdy nazŠv‚ nadsƒťov‚nƒ (supenetting) jako protiklad k podsƒfov‚nƒ (RFC 1518 a 1519). Vyjadřuje se počtem bitů prefixu za IP adresou s lomƒtkem.
Překlad adres: NAT Překlad adres (NAT, Network Address Translation; RFC 3022) je široce využƒvan‚ praxe, kter‚ m‚ v IPv4 dva hlavnƒ „čely: omezit počet glob‚lně jednoznačnŠch IP adres pro priv‚tnƒ sƒtě a vylepšit bezpečnost komunikace mezi priv‚tnƒmi sƒtěmi a Internetem. NAT je dočasnŠm řešenƒm pro nedostačujƒcƒ a neefektivně rozdělenŠ adresnƒ prostor IPv4 (adresa je omezena d•lkou 32 bitů) a bude tu do t• doby, než se postupně přejde k nov• verzi protokolu IP, verzi 6, kter‚ umožňuje jedinečně adresovat opravdu cokoli na zeměkouli (adresa je dlouh‚ 128 bitů).
Sƒť připojujƒcƒ se k Internetu prostřednictvƒm NAT musƒ mƒt alespoň jednu glob‚lně platnou IP adresu, kter‚ je přidělena rozhranƒ směrovače nebo stanice s vƒcen‚sobnŠm připojenƒm k Internetu. Toto NAT zařƒzenƒ prov‚dƒ překlad adres v přƒchozƒch i odchozƒch datagramech tak, že nahrazuje zdrojovou adresu v odchozƒch datagramech svojƒ platnou glob‚lnƒ adresou a cƒlovou adresu v přƒchozƒch datagramech priv‚tnƒ adresou dan• cƒlov• stanice (podle RFC 1918). Z pohledu externƒho uživatele všechny datagramy přich‚zejƒ od NAT zařƒzenƒ a odpovědi jdou na NAT zařƒzenƒ. Z pohledu vnitřnƒho uživatele se jevƒ NAT zařƒzenƒ jako směrovač, kterŠ m‚ přƒstup na Internet. Každ• NAT zařƒzenƒ musƒ mƒt tabulku překladu adres se z‚znamy obsahujƒcƒmi dvojici: IP adresa stanice na Internetu a internƒ IP adresa stanice v priv‚tnƒ sƒti. Tabulka musƒ bŠt k dispozici před tƒm, než přijde datagram z Internetu. Může se iniciovat manu‚lně (staticky) nebo dynamicky (z poolu adres), a to na z‚kladě prohlƒženƒ přƒchozƒch nebo odchozƒch datagramů. Pro mnoh• aplikace je ale princip NAT nepřijatelnŠ, protože nemohou s překladem adres fungovat spr‚vně. NAT nespolupracuje s protokoly, kter• použƒvajƒ informaci o adres‚ch uvnitř samotn•ho datagramů (aplikačnƒ nebo transportnƒ č‚sti řƒdicƒch dat), nikoli pouze v z‚hlavƒ IP datagramů. V z‚hlavƒ jsou adresy přeps‚ny pomocƒ NAT, ale dovnitř do datagramů se NAT nedostane. Modernƒ verze NAT se s tƒm už umƒ vypoř‚dat. NAT principi‚lně neladƒ s mnoha funkčnƒmi z‚měry IP, proto je nerealistick• oček‚vat, že aplikace budou pracovat v přƒtomnosti NAT spr‚vně tak, jak byly navrženy. Mohlo by se zd‚t ž‚doucƒ, aby všechny aplikace tolerovaly NAT. Ale takov‚ tolerance často znamen‚ vŠznamnou bari•ru s ohledem na jejich vŠkonnost a implementaci kvůli potřebě mezilehlŠch prvků pro tunelov‚nƒ skrz NAT. NAT nenƒ bez probl•mů ani pro bezpečnostnƒ mechanismus IPSec , kde je potřeba nav‚zat komunikaci mezi dvěma koncovŠmi adresami. A to se nesrovn‚ se situacƒ, kdy do komunikace vstupuje ještě nějak‚ z‚stupn‚ adresa. IPSec, použƒvajƒcƒ autentizačnƒ z‚hlavƒ (AH), počƒt‚ hodnotu autentizace přes celŠ datagram, včetně zdrojov• a cƒlov• IP adresy. Jak‚koli změna IP adresy, např. prostřednictvƒm překladu adres, vede nevyhnutelně k hodnotě jin• než oček‚van•, a tudƒž k ne„spěšn• autentizaci. Proto je třeba prov‚dět NAT před vlastnƒm zpracov‚nƒm IPSec.
Základní vlastnosti skupinového vysílání KlƒčovŠm cƒlem t•to technologie je z‚sadnƒ odlehčenƒ z‚těže vysƒlajƒcƒho uzlu a přenosov• soustavy při přenosech typu jeden zdroj - mnoho přƒjemců. Zdroj tedy vysƒl‚ data, určen‚ nezn‚m•mu, potenci‚lně velmi velk•mu počtu přƒjemců (skupině), pouze jednou a vešker‚ režie spojen‚ s distribucƒ přƒjemcům je ponech‚na na přenosov• soustavě, v prostředƒ Internetu tedy (v ide‚lnƒm stavu) na směrovačƒch (routerech). Na nich tak• je, aby zajistily efektivnƒ přenos dat od zdroje k přƒjemcům, tedy aby vysƒlan‚ data poslaly po každ•m spoji nejvŠše jedenkr‚t, a to pouze tehdy, je-li danŠm směrem skutečně nějakŠ přƒjemce. Na rozdƒl od klasick•ho přƒm•ho vysƒl‚nƒ (unicast), kdy přenos paketu dat od zdroje k cƒli je iniciov‚n zdrojem, je tok paketů skupinov•ho vysƒl‚nƒ určov‚n přƒjemci. K identifikaci skupin přƒjemců se použƒv‚ speci‚lnƒ třƒda adres IP (třƒda D), zahrnujƒcƒ adresy z množiny 224.0.0.0 až 239.255.255.255. Vysƒlajƒcƒ uzel odesƒl‚ pakety dat s cƒlovou adresou skupiny (a svou vlastnƒ obyčejnou zdrojovou adresou). Dalšƒ šƒřenƒ přes směrovače by mělo (viz RFC 1112) probƒhat stejnou metodou best effort (aneb děl‚m, co můžu) jako šƒřenƒ běžnŠch paketů přƒm•ho vysƒl‚nƒ. V přƒpadě skupinov•ho vysƒl‚nƒ ovšem může směrovač prov•st replikaci paketu a jeho vysl‚nƒ do vƒce směrů.
Skupinov€ vys•l‚n• v lok‚ln• s•ti Protokoly na 2. vrstvě sƒťov• hierarchie (v našich podmƒnk‚ch je z nich daleko nejrozšƒřenějšƒ ethernet) obsahujƒ ve svŠch specifikacƒch podporu skupinov•ho vysƒl‚nƒ v podobě speci‚lnƒch MAC adres. Běžn• sƒťov• karty pracovnƒch stanic (včetně PC) pak majƒ schopnost podle sv•ho okamžit•ho nastavenƒ (na z‚kladě požadavků programu) filtrovat pakety skupinov•ho vysƒl‚nƒ a nejbližšƒm vrstv‚m programov•ho vybavenƒ již před‚vat jen relevantnƒ č‚st paketů skupinov•ho vysƒl‚nƒ, kter• se v lok‚lnƒ sƒti pohybujƒ, tedy pouze skupiny, jež jsou předmětem moment‚lnƒho z‚jmu dan• stanice. Nedoch‚zƒ tedy k zatěžov‚nƒ stanic lok‚lnƒ sƒtě, jichž se dan• skupinov• vysƒl‚nƒ netŠk‚. Z vŠše řečen•ho vyplŠv‚, že napřƒklad k experimentu se skupinovŠm vysƒl‚nƒm v r‚mci lok‚lnƒ sƒtě může postačit běžn• technick• vybavenƒ a přƒslušnŠ aplikačnƒ program (a samozřejmě přƒpadn• dalšƒ technick• prostředky, kter• jsou pro uvažovanou aplikaci potřebn•, např. zvukov‚ karta a reproduktory).
Přenos skupinov€ho vys•l‚n• mezi s•těmi Snadnost implementace skupinov•ho vysƒl‚nƒ v r‚mci lok‚lnƒ sƒtě se vytr‚cƒ, jakmile chceme dos‚hnout přenosu v r‚mci propojenŠch sƒtƒ. Do hry vstupujƒ směrovače s jejich prim‚rnƒm „kolem zƒskat informace o tom, kter• skupiny majƒ bŠt vysƒl‚ny do sƒtƒ, jež jsou ke směrovači bezprostředně připojeny. K tomuto „čelu byl vyvinut speci‚lnƒ protokol IGMP, Internet Group Management Protocol. Jeho pomocƒ směrovač periodicky zjišťuje z‚jem stanic v připojenŠch sƒtƒch o jednotliv• proudy skupinov•ho vysƒl‚nƒ. Směrovač vyšle do připojen• sƒtě dotaz (paket se speci‚lnƒ skupinovou adresou 224.0.0.1) a jednotliv• stanice odpovƒdajƒ (s n‚hodně zvolenŠm zpožděnƒm, aby nedoch‚zelo k zahlcenƒ sƒtě při současn• odpovědi všech najednou) informacƒ o adres‚ch skupinov•ho vysƒl‚nƒ, o něž majƒ z‚jem. Odpovědi jsou rovněž vysƒl‚ny na adresu 224.0.0.1 a odposlouch‚v‚ny ostatnƒmi stanicemi. Tƒm se zamezƒ duplicitnƒmu vysƒl‚nƒ požadavků na stejnou skupinu. Programov• vybavenƒ koncov• stanice tedy musƒ navƒc podporovat protokol IGMP. Směrovače tak pomocƒ protokolu IGMP sledujƒ z‚jem o přƒjem konkr•tnƒch skupin ve sv•m bezprostřednƒm okolƒ.
Směrov‚n• skupinov€ho vys•l‚n• Směrovače musejƒ - kromě trval•ho mapov‚nƒ sv•ho bezprostřednƒho okolƒ - zajistit tok paketů skupinov•ho vysƒl‚nƒ i do vzd‚lenŠch oblastƒ sƒtě, a to pokud možno optim‚lnƒm způsobem. K tomu sloužƒ tzv. směrovac‚ protokoly. Jejich pomocƒ směrovače hledajƒ minim‚lnƒ strom spojů pokrŠvajƒcƒ cestu od zdroje skupinov•ho vysƒl‚nƒ k moment‚lnƒm z‚jemcům o přƒjem. Je zřejm•, že na rozdƒl od klasick•ho směrov‚nƒ přƒm•ho vysƒl‚nƒ půjde o proces velmi dynamickŠ. Cesta od dan•ho zdroje k dan•mu cƒli je totiž st‚l‚, pokud nedojde k nějak• vnějšƒ ud‚losti měnƒcƒ topologii sƒtě, např. poruše linky. Naproti tomu z‚jemci o přƒjem dan•ho skupinov•ho vysƒl‚nƒ mohou vznikat a zanikat trvale a tento proces průběžnŠch změn musejƒ směrovacƒ protokoly vhodně reflektovat. Směrovacƒ protokoly skupinov•ho vysƒl‚nƒ jsou dosud předmětem intenzivnƒho vŠzkumu a vŠvoje. V současn• době se nejvƒce použƒvajƒ protokoly DVMRP (Distance Vector Multicast Routing Protocol) a dvě varianty protokolu PIM (Protocol Independent Multicast).
Moment‚ln• dostupnost a aplikace skupinov€ho vys•l‚n• Dosavadnƒ vŠklad, kdy jsme nerozlišovali mezi běžnŠm směrovačem a směrovačem podporujƒcƒm skupinov• vysƒl‚nƒ, mohl v•st k dojmu, že podpora skupinov•ho vysƒl‚nƒ je
organickou souč‚stƒ všech směrovačů, a to od nepaměti. Skutečnost je však trochu složitějšƒ. Přestože různ• normy pamatujƒ na skupinov• vysƒl‚nƒ již delšƒ dobu (vŠše citovanŠ RFC1112 poch‚zƒ z roku 1989), nar‚želi vŠvoj‚ři aplikacƒ skupinov•ho vysƒl‚nƒ dlouhou dobu na tvrzenƒ vŠrobců směrovačů, že skupinov• vysƒl‚nƒ nenƒ třeba podporovat, protože nejsou jeho aplikace. Cesta z t•to pasti vedla přes implementaci speci‚lnƒch skupinovŠch směrovačů (multicast router, mrouter) do pracovnƒch stanic připojenŠch do lok‚lnƒch sƒtƒ experimentujƒcƒch se skupinovŠm vysƒl‚nƒm. Jejich vz‚jemn• propojenƒ zprostředkovaly tzv. tunely, kdy pakety skupinov•ho vysƒl‚nƒ byly zabaleny do přƒm•ho vysƒl‚nƒ mezi mroutery. V současn• době je situace o pozn‚nƒ přƒznivějšƒ, prakticky každŠ průmyslově vyr‚běnŠ směrovač podporuje skupinov• vysƒl‚nƒ a některŠ směrovacƒ protokol. I tak ovšem nejsou vyloučena nepřƒjemn‚ překvapenƒ, zejm•na při změn‚ch verzƒ programov•ho vybavenƒ směrovačů. Rovněž spolupr‚ce směrovačů různŠch vŠrobců m‚ blƒže k dobrodružstvƒ než k rutinnƒ z‚ležitosti. V r‚mci p‚teřnƒ sƒtě TEN-34CZ je zhruba rok implementov‚na podpora skupinov•ho vysƒl‚nƒ do všech koncovŠch směrovačů t•to sƒtě na b‚zi směrovacƒho protokolu PIM. Dalšƒ šƒřenƒ do č‚stƒ brněnsk• metropolitnƒ sƒtě je podmƒněno moment‚lnƒmi možnostmi použitŠch směrovačů a je předmětem dalšƒho vŠvoje. Jak již bylo zmƒněno v „vodu, dosavadnƒ aplikace směřovaly předevšƒm do oblasti multim•diƒ. V podstatě jednosměrnŠ přenos obrazu a zvuku totiž toleruje jistŠ stupeň nespolehlivosti přenosu, aniž by došlo k tot‚lnƒmu znehodnocenƒ cel• aplikace. Pohyb obrazu je m•ně souvislŠ, zvuk m‚ vŠpadky, ale obojƒ lze až po jistou mez tolerovat. Zatƒm asi nejkomplexnějšƒ aplikacƒ skupinov•ho vysƒl‚nƒ byl a je projekt sƒtě MBONE, jƒmž se zabŠv‚ přƒspěvek Videokonference na Internetu: snadno a rychle v tomto čƒsle Zpravodaje.
