v. 2.2 Katedra softwarového inženýrství, Matematicko-fyzikální fakulta, Univerzita Karlova, Praha Rodina protokol, verze 2.2 ást 2: Architektura Jií Peterka, 2004
v. 2.2 Motto Víš-li, jak na to, tyi vrstvy ti pln postaí...... nevíš-li, ani sedm ti jich nepomže J.Peterka, MFF UK, 2005 2
v. 2.2 V em se liší a ISO/OSI? v celkovém pístupu autor ISO/OSI: všechno musíme vymyslet sami (nebo alespo pevzít to, co vymysleli jiní, a udlat z toho vlastní standard) píklad: ISO vydává Ethernet jako svj standard ISO 8802.3 : to co je rozumné pevezmeme a využijeme soustedí se na "provázání" vlastních ešení s cizími eší nap. jak provozovat IP nad Ethernetem ve zpsobu tvorby nových ešení: ISO/OSI: od složitého k jednoduššímu ešení vznikají od zaátku jako "dokonalá" nejprve navymýšlí vzdušné zámky, pak musí slevovat nejprve vznikne standard, pak se zkoumá praktická realizovatelnost : od jednoduššího ke složitjšímu ešení vznikají nejprve jako "skromná", postupn se obohacují nejprve se ešení oví, a teprve pak vzniká standard J.Peterka, MFF UK, 2005 3
v. 2.2 Konkrétn. v pohledu na poet vrstev a zpsob jejich fungování jaké služby mají být nabízeny a na jaké úrovni mají být poskytovány kde má být zajišována spolehlivost jak mají služby fungovat spolehlivost/nespolehlivost, spojovanost/nespojovanost, princip maximální snahy vs. garance kvality služeb, zda má být ponechána možnost volby mají aplikace právo si vybrat nap. mezi spolehlivým a nespolehlivým penosem? aplikaní vrstva transportní v. síová vrstva (IP vrstva) vrstva síového rozhraní ISO/OSI aplikaní v. prezentaní v. relaní v. transportní v. síová v. linková v. fyzická v. J.Peterka, MFF UK, 2005 4
v. 2.2 Pohled do historie již pi budování sít ARPANET se uplatnila nkterá koncepní rozhodnutí, která "vydržela" až do dnešního Internetu a nedlat žádný centrální prvek (uzel, ústednu,...) protože nepítel by jej odstelil jako první dnešní Internet stále nemá žádný centrální prvek (ídící centrum, ) platí to jak pro technické fungování, tak i pro ízení pedem poítat s výpadky a s nespolehlivostí jako kdyby kterákoli ást již byla odstelena i poškozena dsledek: ARPANET (i Internet) jsou ešeny velmi robustn mají velmi dobrou schopnost adaptability, dokáží se pizpsobit podmínkám, "vydržel" i samotný princip paketového penosu (packet switching), namísto pepojování okruh (circuit switching). J.Peterka, MFF UK, 2005 5
v. 2.2 Dsledky obliba nespojované (connectionless) komunikace penosové mechanismy fungují na nespojovaném principu, teprve vyšší vrstvy mohou fungovat spojovan, resp. komunikovat se svými protjšky na spojovaném principu obliba nespolehlivého penosu teze: penosové mechanismy se mají starat o penos a dlat jej co nejefektivnji nemají se ohlížet na event. ztráty dat fungování na principu maximální snahy, ale nezarueného výsledku penosové mechanismy se maximáln snaží, ale když se jim nco objektivn nedaí, mají právo se na to "vykašlat" J.Peterka, MFF UK, 2005 6
v. 2.2 Nespojovaná komunikace penosové služby fungují na nespojovaném principu nenavazují spojení, posílají data v dobré víe že píjemce existuje a bude ochoten je pijmout hlavní penosový protokol síové vrstvy (protokol IP) je nespojovaný výhody: je to bezestavové nemní se stav odesilatele ani píjemce není nutné složit reagovat na zmny v penosové infrastruktue, rušením a novým navazováním spojení vše zajistí adaptivní mechanismy smrování výhody/nevýhody: je to výhodné pro "ídké" penosy penosy menších objem dat, hodn rozložené v ase není to výhodné pro "intenzivní" penosy penosy vtších objem dat v krátkém asovém intervalu vyšší vrstvy mohou fungovat spojit týká se to pedevším jejich komunikace, ne samotného penosu (na úrovní síové vrstvy) transportní protokol (TCP) vytváí iluzi spojovaného penosu J.Peterka, MFF UK, 2005 7
v. 2.2 Nespolehlivá komunikace spolehlivost penosu není nikdy absolutní (100%), je vždy pouze relativní (nap. 99%) dvod: již samotné mechanismy detekce chyb nejsou 100% nkomu mže konkrétní míra spolehlivosti stait, jinému ne zajištní spolehlivosti je vždy spojeno s nenulovou režií spotebovává to výpoetní kapacitu, penosovou kapacitu, pokud by spolehlivost zajišovalo více vrstev nad sebou, režie se sítá (násobí) není to rozumné to nechce dlat, ISO/OSI to dlá zpsobuje nerovnomrnosti (nepravidelnosti) v doruování dat tím, že se opakuje penos chybn penesených dat vadí to hlavn u multimediálních penos zvolenéešení v rámci : spolehlivost není nikomu vnucována každá aplikace si mže vybrat: zda vystaí s nespolehlivým penosem, event. si spolehlivost zajistí sama nebo zda využije spolehlivost kterou nabízí spolehlivý transportní protokol J.Peterka, MFF UK, 2005 8
v. 2.2 Jiný pohled na spolehlivost spolehlivost je o tom, kde v síti má být umístna "inteligence" výpoetní kapacita, logika implementující zajištní spolehlivosti pipomenutí: síová vrstva je ješt ve všech uzlech, transportní již jen v koncových uzlech ISO/OSI: inteligence má být v síti spolehlivost musí být ešena na úrovni síové vrstvy inteligence je ve smrovaích je to drahé a nepružné nedává to možnost výbru : inteligence má být v koncových uzlech spolehlivost je ešena až v transportní vrstv je to lacinjší, pružnjší umožuje to, aby si aplikace vybíraly zda spolehlivost chtjíi nechtjí teze (): penosová vrstva se má starat o penos dat má to dlat co nejefektivnji nemá se rozptylovat dalšími úkoly (nap. zajišováním spolehlivosti, když to si snáze a lépe zajistí koncové uzly sít) zajištní spolehlivosti je úkolem koncových uzl transport. vrstva síová vrstva vrstva sí. rozhraní koncový uzel síová vrstva vrstva sí. rozhraní smrova transport. vrstva síová vrstva vrstva sí. rozhraní koncový uzel J.Peterka, MFF UK, 2005 9
v. 2.2 Hloupá sí vs. chytré uzly jiná interpretace: penosováást sít (IP sí) má být "hloupá" ale efektivní, má co nejrychleji a nejefektivnji plnit své základní úkoly "chytré" mají být koncové uzly inteligence má být soustedna do koncových uzl IP sí inteligence rychlost inteligence J.Peterka, MFF UK, 2005 10
v. 2.2 Princip maximální snahy anglicky"best effort" penosováást sít se maximáln snaží vyhovt všem požadavkm, které jsou na ni kladeny pokud se jí to nedaí, má právo krátit požadavky (limitovat, ignorovat je, nevyhovt jim, ) nap. pozdržet penášené pakety do doby, než je bude moci zpracovat mže i zahazovat pakety, které vbec nedokáže zpracovat dlá to rovnomrn vi všem požadavkm "mí všem stejn", nepracuje s prioritami je to celková filosofie je praktickým dsledkem použití paketového penosu a pístupu ke spolehlivosti alternativa: garance služeb (QoS, Quality of Service) QoS nabízí telekomunikaní sít výhoda: sít fungující na principu "best effort" jsou mnohem efektivnjší (i ekonomicky) než sít nabízející QoS kdyby Internet poskytoval QoS, byl by mnohem dražší než dnes a mén rozvinutý nevýhoda: vadí to multimediálním penosm J.Peterka, MFF UK, 2005 11
v. 2.2 Pohled do historie II. koncepce protokol vznikala v dob, kdy se rodil Internet když se na tehdejší zárodený ARPANET nabalovaly další sít byly to sít, kteréasto fungovaly na jiné technologické platform používaly rzné penosové technologie, rzné adresy, rzné pístupy ke spolehlivosti, ke spojovanosti, rzné velikosti rámc atd. cíl : umožnit plnohodnotné pipojení jakýchkoli sítí fakticky: draz na internetworking konkrétn: šlo o to, aby protokoly mohly být používány nad nejrznjšími penosovými technologiemi týká se to hlavn protokolu IP výsledek: podailo se, dnes je možné provozovat IP nad ímkoli "IP over everything" bylo teba pijmout mnoho koncepních rozhodnutí, které s tím byly spojeny zpsob propojení dílích sítí adresování "viditelnost" specifických vlastností penosových technologií vazbu na fyzické (linkové) penosové technologie. J.Peterka, MFF UK, 2005 12
v. 2.2 Píiny úspchu vlastní systém adresování zabudovaný do mechanism fungování umožuje identifikovat a adresovat uzly (zaízení) i dílí entity (služby atd.) bez znalosti detail jejich pipojení IP a DNS, nov ENUM souástí je systém celosvtové koordinace pidlování IP adres, stromová struktura DNS systém adresování se dokázal uzpsobit stále vtšímu rozsahu sítí výjimka: rozsah adres IPv4, vznik IPv6 dobrá škálovatelnost pvodníešení vzniklo pro sít s desítkami uzl dnes funguje pro Internet s miliony uzl v zásad beze zmny výjimka: IPv4 IPv6 základní rozhodnutí vznikla ped 30 lety a dodnes se nemusela mnit zmny v byly spíše "inkrementálního" charakteru nco se pidalo J.Peterka, MFF UK, 2005 13
v. 2.2 Píiny úspchu podpora internetworkingu a smrování protokoly vychází dobe vstíc vzájemnému propojování sítí obsahují další protokoly pro podporu práce smrova ICMP, Interior a Exterior Routing Protocols nezávislost na fyzických (linkových) technologiích protokoly (hlavn IP) dokáží bžet nad každou penosovou technologií nižších vrstev "IP over everything" univerzálnost, dobrá podpora aplikací lze využít pro všechny aplikace by nkterým s evychází vstíc mén aplikacím není vnucováno, co a jak mají používat volba TCP vs. UDP výsledek: "Everything over IP" otevený, neproprietární charakter standardy jsou otevené a pístupné každému proces vzniku standard je otevený J.Peterka, MFF UK, 2005 14
v. 2.2 Koncepce : katenetový model pedpokládá že "svt" (internetwork, internet) je: tvoen soustavou dílích sítí chápaných jako celky na úrovni síové vrstvy, tzv. IP sítí dílí sít jsou vzájemn propojeny na úrovni síové vrstvy pomocí smrova (díve nazývaných IP Gateways, dnes: IP Routers) toto propojení mže být libovolné mže být stylem "každý s každým", nebo "do etzce" apod. jedinou podmínkou je souvislost grafu "katenet" je "etzec" ten je jakousi minimální podmínkou pro souvislost celé soustavy sítí možné je i redundantní propojení pedstava katenetu skutená sí = IP sí = IP Router J.Peterka, MFF UK, 2005 15
v. 2.2 Hostitelské poítae vs. smrovae pedpokládá, dva typy uzl v síti: hostitelské poítae (host computers) tj. koncové uzly, nap. servery, pracovní stanice, PC, rzná zaízení (tiskárny, ) jsou pipojeny jen do jedné IP sít (mají jen jednu síovou adresu) smrovae (IP Routers, díve nesprávn IP Gateways) jsou pipojeny nejmén do dvou IP sítí zajišují "pestup" (smrování) teze: oba typy uzl by se nemly prolínat smrovae by nemly plnit další funkce hostitelské poítae by nemly fungovat jako smrovae v podob tzv. multihomed-hosts, kdy jsou pipojeny do více sítí souasn IP sí = smrova IP sí + + + =hostitelské poítae (hosts) = multihomed host IP sí IP sí IP sí J.Peterka, MFF UK, 2005 16
v. 2.2 Vrstva síového rozhraní aplikaní vrstva transportní v. síová v. (IP v.) vrstva síového rozhraní "poklika" protokol IP nepokrývá protokoly pokrývají se nezabývá tím, co je pod úrovní síové vrstvy pesnji: sám nedefinuje protokoly které fungují "pod" síovou vrstvou (na úrovni vrstvy síového rozhraní) jde nap. o Ethernet, ATM, Token Ring, FDDI, Frame Relay zamuje se pouze na to, jak propojit síovou vrstvu s vrstvou síového rozhraní nap. jak provozovat IP nad Ethernetem, nad ATM... výjimka: protokoly SLIP a PPP definují zpsob penosu po dvoubodových spojích zasahují až do vrstvy síového rozhraní dsledek: nezávislost na fyzické (linkové) penosové technologii J.Peterka, MFF UK, 2005 17
v. 2.2 Síová vrstva: dilema pokliky Autoi se museli rozhodnout, zda: vytvoí jednotnou nadstavbu nad soustavou vzájemn propojených sítí penosový protokol na úrovni síové vrstvy (IP protokol), který bude mít všude stejné vlastnosti a poskytovat stejné služby stejné adresování. ano ne vyšší vrstvy mohou být jednotné, nemusí se zabývat odlišnostmi nebo zda nadstavba nebude všude stejná tj. protokol IP bude mít v rzných sítích rzné vlastnosti, resp. nabízet rzné služby. ne ano umožuje to dosahovat maximální možné efektivnosti, pizpsobením se specifickým vlastnostem penosových mechanism J.Peterka, MFF UK, 2005 18
v. 2.2 Výsledek koncepce síové vrstvy autoi se rozhodli pro "jednotnou pokliku", která zastírá konkrétní specifika jednotlivých IP sítí fakticky jde o jednotnou nadstavbu, kterou tvoí: penosový protokol IP, který má všude stejné vlastnosti a všude poskytuje stejné služby je nespojovaný, nespolehlivý, funguje na principu maximální snahy jednotné adresování virtuální 32-bitové adresy (nemají žádný reálný vzor), tzv. IP adresy tyto adresy by mly vyhovovat "pohledu na svt", který má že svt je tvoen dílími sítmi a hostitelskými poítai (a smrovai) IP adresy mají "síovou ást", identifikující sí jako celek, a dále "uzlovou ást", identifikující uzel v rámci sít existuje ale jedna výjimka: IP protokol i vyšší vrstvy "vidí" maximální velikost linkového rámce (skrz parametr MTU, Maximum Transfer Unit) a mli by jej respektovat tak aby nedocházelo ke zbytené fragmentaci pi penosech J.Peterka, MFF UK, 2005 19
v. 2.2 Pedstava pokliky jednotné prostedí aplikace transport. vrstva síová vrstva vrstva sí. rozhraní koncový uzel transportní protokol MTU aplikace síová vrstva vrstva sí. rozhraní smrova aplikace poklika transportní protokol transport. vrstva síová vrstva aplikace vrstva sí. rozhraní koncový uzel J.Peterka, MFF UK, 2005 20
v. 2.2 Souásti síové vrstvy v síové vrstv jsou "zabudovány": síové adresy 32-bitové abstraktní adresy nevychází z linkových adres pevodní mechanismy, které pekládají mezi fyzickými (linkovými) adresami a virtuálními IP adresami protokoly ARP, RARP,. mechanismy fragmentace vazba na MTU protokoly na podporu fungování síové vrstvy protokol ICMP "posel špatných zpráv" zajišuje informování o nestandardních situacích se síovou vrstvou úzce souvisí: protokoly podporující smrování a výmnu aktualizaních informací o stavu sít RIP, OSPF, IGP, EGP, mechanismy pidlování IP adres mechanismy pekladu mezi symbolickými doménovými jmény a IP adresami do síové vrstvy byly nov pidány také mechanismy pekladu adres NAT koncept privátních IP adres mechanismy dlení adres a sdružování adres subnetting, supernetting, CIDR bezpenostní mechanismy IPSec podpora mobility J.Peterka, MFF UK, 2005 Mobile IP 21
v. 2.2 Koncepce transportní vrstvy realizuje "end-to-end" komunikaci nabízí dva transportní protokoly TCP (Transmission Control Protocol) funguje spojovan vyžaduje navázání/ukonení spojení.. od aplikace pebírá data po bytech jako "bytový proud" ale sám data penáší po blocích, jako tzv. TCP segmenty funguje spolehliv zajišuje spolehlivý penos používá kontinuální potvrzování a selektivní opakování je velmi adaptivní dokáže se prbžn pizpsobovat rzným podmínkám penosu penosové zpoždní, rozptyl zpoždní atd. je velmi komplikovaný velký a složitý kód, UDP (User Datagram Protocol) je pouze jednoduchou nadstavbou nad síovým protokolem IP jeho kód je malý a jednoduchý funguje nespojovan nenavazuje spojení funguje nespolehliv od aplikace pebírá data po blocích a vkládá je do svých "datagram" UDP datagram, User datagram transportní vrstva zajišuje multiplex/demultiplex adresuje entity v rámci jednotlivých uzl pomocíísel port J.Peterka, MFF UK, 2005 22
v. 2.2 Koncepce transportní vrstvy "realizuje demokracii": penosové mechanismy do úrovn síové vrstvy fungují nespolehliv na úrovni transportní vrstvy jsou dva alternativní protokoly UDP, nespojovaný, nespolehlivý TCP, spojovaný, spolehlivý aplikace si mohou samy vybrat, zda budou používat TCP nebo UDP transportní vrstva SMTP RPC rlogin FTP Telnet HTTP DNS aplikace aplikace aplikace aplikace síová vrstva TCP IP UDP SNMP TFTP BOOTP DHCP RPC NFS XDR aplikaní vrstva TCP UDP transportní vrstva J.Peterka, MFF UK, 2005 23
v. 2.2 Prezentaní a relaní služby v ISO/OSI má samostatnou prezentaní a relaní vrstvu vychází z pedpokladu že prezentaní a relaní služby budou potebovat všechny aplikace pak mají samostatné vrstvy smyl nemá samostatné vrstvy vychází z pedpokladu, že prezentaní a relaní služby budou potebovat jen nkteré aplikace pak nemá smysl dlat samostatné vrstvy aplikace, které tyto služby potebují, si je musí realizovat samy aplikaní vrstva transportní v. ISO/OSI aplikaní v. prezentaní v. relaní v. transportní v. J.Peterka, MFF UK, 2005 24
v. 2.2 Výjimka: RPC a XDR aplikaní protokol NFS používá ke svému fungování prezentaní a relaní služby protokol RPC (Remote Procedure Call) pro relaní služby) protokol XDR (external Data Representation) pro prezentaní služby tyto protokoly jsou implementovány jako vícenásobn využitelné jako samostatné moduly, jejichž služby mže využívat každá aplikace která chce a naopak nemusí ta aplikace, která nechce (a v tom pípad nenese jejich režii!!!!) aplikace aplikace aplikaní vrstva XDR RPC transportní vrstva aplikace J.Peterka, MFF UK, 2005 25
v. 2.2 Aplikace v pvodn: elektronická pošta (SMTP, RFC 822) penos soubor (FTP) vzdálené pihlašování(telnet, rlogin) tmto aplikacím dobe vyhovovalo fungování sít "na principu maximální snahy, ale nezarueného výsledku" pozdji se objevily a prosadily nové aplikace: news sdílení soubor (NFS) WWW (HTML, HTTP,.) on-line komunikace (chat, IRC, ICQ, messengery, ) princip maximální snahy je pro n stále ješt akceptovatelný by ne ideální pozdji se objevují "multimediální" aplikace "audio over IP" VOIP IPTV rozhlasové vysílání Voice over IP, IP telefonie TV over IP, TV na žádost po IP pro tyto aplikace princip "maximální snahy" není optimální, ale ješt postauje, dležitá je hlavn disponibilní penosová kapacita dochází k "platformizaci" aplikací pvodn samostatné aplikace se pesouvají do role nadstavby na platform jiné aplikace nejastji WWW J.Peterka, MFF UK, 2005 26
v. 2.2 Aplikace v prakticky všechny aplikace v rámci jsou založeny na architektue client/server servery poskytující "veejné" služby jsou dostupné na tzv. dobe známých portech (well-known ports) penosové mechanismy jsou uzpsobeny komunikaci stylem 1:1 (mezi 1 serverem a 1 klientem) klient komunikace server penos dat transport. vrstva transport. vrstva síová vrstva síová vrstva síová vrstva vrstva sí. rozhraní vrstva sí. rozhraní vrstva sí. rozhraní koncový uzel smrova koncový uzel J.Peterka, MFF UK, 2005 27
v. 2.2 Problém distribuních aplikací s postupem asu se objevily i takové aplikace, pro které je fungování penosových mechanism principiáln nevhodné "distribuní služby" = videokonference, vysílání rozhlasu a TV,. potebují dopravovat stejná data od 1 zdroje k více píjemcm souasn tzv. multicasting (event. broadcasting) penosové mechanismy to neumí!!! penosové mechanismy poítají s penosem 1:1 (od jednoho zdroje k jednomu píjemci) pokus: služba MBONE (nepíliš úspšná) eší se až v rámci IPv6 a IP Multicast Initiative netýká se VOIP a IPTV, to jsou služby s penosy typu 1:1 bez multicastingu s multicastingem J.Peterka, MFF UK, 2005 28
v. 2.2 Problém multimediálních aplikací potebují dostávat svá data: s malým zpoždním s pravidelným zpoždním s pravidelnými odstupy mezi sebou týká se to napíklad penosu živého obrazu i zvuku aplikace VOIP, TV vysílání, rozhlas, video-on-demand problém je s fungováním penosových mechanism na principu "maximální snahy, ale nezarueného výsledku" byla by zapotebí podpora QoS (kvality služeb) QoS je v zásad "protipólem" principu maximální snahy možnáešení: "kvantitativní": zvyšování disponibilní kapacity fungování na principu "maximální snahy " zstává zlepšení je statistické je menší pravdpodobnost, že bude muset dojít ke krácení požadavk týká se: penosových kapacit (tj. linek) "pepojovacích kapacit" (smrova, switch) "kvalitativní": zavedení podpory QoS fungování na principu "maximální snahy " je nahrazeno jiným zpsobem fungování zlepšení je garantované ale drahé a obtížné J.Peterka, MFF UK, 2005 29
v. 2.2 QoS v možné pístupy prioritizace rezervace rzným druhm penos se piadí rzné priority a je s nimi nakládáno odlišn penosy s vyšší prioritou dostávají "kvalitnjší obsluhu" (a pídl zdroj) na úkor penos s nižší prioritou píklady ešení: DiffServ Differentiated Services "hrubá síla" MPLS MultiProtocol Label Switching pro potebu konkrétních penos si lze vyhradit (rezervovat) požadované zdroje a ty pak využívat týká se i vyhrazení penosové kapacity, pepojovací kapacity atd. píklady ešení: IntServ (Integrated Services) RSVP (ReSource reservation Protocol) princip "best effort" se nemní, pouze se pedimenzují dostupné kapacity tak aby nedocházelo ke kapacitním problémm tak asto J.Peterka, MFF UK, 2005 30
v. 2.2 Problém bezpenosti Penosové mechanismy neposkytují žádné zabezpeení nebylo to "v pvodním zadání" ARPANET (budoucí Internet) byl tehdy spíše privátní sítí, jeho uživatelé byli "hlídáni" jinak uživatelé byli "dobe známí" spíše se aplikovala "fyzická bezpenost" ochrana budov, zaízení atd. penášená data nejsou žádným zpsobem chránna proti "odposlechu" nejsou šifrována ani jinak kódována i chránna chybí tzv. dvrnost nejsou ani chránna proti ztráti zmn pi nespolehlivému penosu chybí tzv. integrita pedpoklad: pokud njaká aplikace potebuje uritou míru zabezpeení, musí si ji zajistit sama jde o stejný "kompromis" jako u spolehlivosti: buto poskytnout zabezpeení všem (i tm kteí jej nepotebují), nebo si jej bude muset každý zájemce udlat sám teze: penosové mechanismy by mly hlavn penášet data, ne se starat o další funkce dsledek: penosová infrastruktura je jednodušší, rychlejší a také lacinjší oproti stavu, kdy by fungovala zabezpeeným zpsobem praxe: zabezpeení se eší na aplikaní úrovni IPSEC: asem byl vypracován celý framework (rámec) pro zajištní bezpenosti ješt na úrovni síové vrstvy J.Peterka, MFF UK, 2005 31
v. 2.2 IP Security (IPSec) je to celý rámec (framework) nejde o (jeden) konkrétní protokol ale o soustavu vzájemn provázaných opatení a dílích protokol nejde o jeden internetový standard je definován nkolika RFC funguje na síové úrovni!!! IPSec pvodn vznikl pro IPv6 ale zaal se používat i pro stávající IPv4 IPSec zajišuje: dvrnost šifruje penášená data integritu že penášená data nejsou pi penosu zmnna umožuje: aby si komunikující strany dohodly algoritmy a klíe pro zabezpeení svých penos chrání i proti nkterým druhm útok nap. "replay attack" má dva režimy fungování: transport mode "zabezpeovací údaje" se vloží pímo do IP datagram do jeho hlaviky a za ni tunnel mode IP datagram se vloží do jiného (zabezpeeného) datagramu J.Peterka, MFF UK, 2005 32
v. 2.2 IP verze 6 197x: rozhodnutí o 32-bitových IP adresách, IPv4 tehdejší pedstava: ARPANET mže mít až tisíce uzl dnes: Internet má milionu uzl 198x/9x: zaíná hrozit nebezpeí vyerpání 32- bitového adresového prostoru IAB zaíná problém ešit vzniká samostatná oblast (area) v rámci IETF doasnáešení - usilují zpomalit úbytek IP adres písnjší zpsob pidlování IP adres subnetting privátní IP adresy mechanismus CIDR doasnáešen významn uspla v oddálení problému nebezpeí vyerpání se stalo mén akutní souasn se zaalo pracovat na "definitivním" ešení zjištní: 32-bitové adresy jsou v protokolu IP tak hluboce "zakoenny", že není zvtši adresový prostor ješt v rámci téhož IP (IPv4) je nutné vyvinout zcela nový protokol IP!!! s vtším adresovým prostorem, ale i dalšími zmnami dnes používaný protokol IP je verze 4 IPv4 nový protokol IP je verze 6 IPv6 IPv5 neexistuje IPnG (IP The Next Generation) obecné oznaení pro všechny návrhy, které se sešly v rámci IETF pi hledání nové verze IPv6 je jeden z protokol IPnG nkdy se bere IPv6=IPnG J.Peterka, MFF UK, 2005 33
v. 2.2 Koncepce IPv6 používá adresy v rozsahu 128 bit celkem 340'282'366'920'938'463'463'374'607'431'768'211'456 unikátních IPv6 adres každý dnes žijícílovk by mohl dostat na 4 miliardy adres, každé zrnko písku na plážích svta by mohlo dostat na 2128 rzných adres na každý tverení mikrometr zemského povrchu by pipadlo na 5000 adres IPv6 128- bitový adresový prostor je hierarchicky lenn multicast adresy, lokální adresy pro sít a segmenty, pro ISP, "IPv4 embedded". má nový formát IP datagramu "IPv6 datagramu" nabízí rzné strategie pidlování IP adres vetn možnosti, aby si uzel sám uril svou vlastní IP adresu podle toho, jak je naadresováno jeho okolí podporuje hierarchické smrování, bezpenost, kvalitu služeb (QoS), nemá broadcast, má unicast, multicast a nov také "anycast" J.Peterka, MFF UK, 2005 34
v. 2.2 a mobilita mobilita IP adresy nejsou "mobilní" nelze je penášet mezi sítmi smruje se na základ IP adres, podle jejich síovéásti nelze jen tak "vytrhnout" jednotlivé IP adresy z jejich "mateské" sít protokol IP vznikal v dob, kdy poítae nebyly penosné, nebyl požadavek na mobilitu ešení mobility: pidlení nové IP adresy v nové síti BOOTP, DHCP atd. skrze agenty a tunely "na pvodním míst" zstane agent, který vše peposílá "skrze tunel" tam, kde se uzel práv nachází jinak IP Mobility Support "Mobile IP" RFC 2002 a další (3220, 3344) princip fungování: metoda "agent" pakety jsou smrovány na pvodní místo, odkud jsou následn peposílány na nové místo pro vyšší vrstvy je to neviditelné vzdálené zaízení nemusí Mobile IP podporovat vše zaizuje agent, mobilní zaízení o tom neví je to ureno pro "píležitostnou mobilitu" nap. pohyb 1x za týden nikoli pro "astou mobilitu", jako nap. v mobilních sítích, roaming apod. mobilní zaízení musí mít staticky piazenou IP adresu J.Peterka, MFF UK, 2005 35