SpeciÄlnÅ IP adresy NěkterÅ IP adresy jsou vyhrazeny pro speciçlné Ñčely:

Transkript

1 SpeciÄlnÅ IP adresy NěkterÅ IP adresy jsou vyhrazeny pro speciçlné Ñčely: Rozsah od do 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 do patřé do třédy E. Tyto hodnoty jsou rezervovçny pro dalšé použité a pro experimentçlné Ñčely nebo 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, 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 : až TřÅda B : až TřÅda C : až Multicast IP adresy Multicast adresné rozsahy: až určenå pro séťovå protokoly uvnitř LAN, majé TTL = 1, takže nepřejdou přes router až jsou globçlné multicast adresy, kterå se použévajé mezi organizacemi a přes internet až je omezenä rozsah adres, pro použité uvnitř organizace (LAN)

2 NěkterÅ speciçlné adresy: skupina všech stanic připojenäch k lokçlné podséti, skupina všech směrovačů připojenäch k lokçlné podséti, skupina všech směrovačů podporujécéch směrovacé protokol OSPF 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 2 x 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ů).

3 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 až 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ů.

4 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 ) 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 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

5 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.