IP protokol poskytuje mechanizmus na odosielanie cez internet prvkov tzv IP datagramy(IP datagram). Ako je znázornené na obr. 6.1 je IP datagram vytvorený z IP hlavičky a časti dát prechádzajúcej sieťou.

Ryža. 6.1. Formát datagramu

Protokol IP možno nazvať „protokolom s najlepším úsilím“. To znamená, že IP nezaručuje integritu doručenia datagramu na miesto určenia, ale iba najlepší pokus o doručenie (pozri obrázok 6.2). Datagram môže byť poškodený z nasledujúcich dôvodov:

■ Chyba v jednom z bitov počas prenosu na médiu.

■ Preťažený smerovač zrušil datagram, aby uvoľnil miesto vo vyrovnávacej pamäti.

■ Cesta k cieľu je dočasne nedostupná.

Ryža. 6.2. Doručenie do IP na základe najlepšieho pokusu

Všetky operácie na zabezpečenie spoľahlivosti doručovania údajov sa vykonávajú na úrovni TCP. Obnova poškodených údajov závisí od akcií na tejto úrovni.

6.3 Základné funkcie IP

Hlavné funkcie IP sú: príjem dát z TCP alebo UDP, vytvorenie datagramu, jeho smerovanie cez sieť a jeho doručenie do prijímajúcej aplikácie. Každý IP datagram je smerovaný samostatne. Existujú dva spôsoby smerovania datagramu na IP:

■ Masku podsiete

■ smerovacia tabuľka IP (smerovacia tabuľka)

6.4 Používanie masky podsiete

Predpokladajme, že počítač má IP adresu 130.15.12.131 a je pripojený k lokálna sieť a údaje je potrebné odoslať:

Od: 130.15.12.131

B: 130.15.12.22

Dá sa predpokladať, že oba systémy sú na rovnakej podsieti. Počítač musí skontrolovať, či je takýto predpoklad správny. Kontrola sa vykonáva pomocou masky podsiete. Povedzme, že hostiteľ má masku podsiete:

tie. existuje maska ​​pozostávajúca z 24 jednotiek a 8 núl:

11111111111111111111111100000000

Pripomeňme, že tie v maske podsiete identifikujú sieť a časť adresy pre podsiete. Keďže časti zdrojovej a cieľovej adresy siete a podsiete sú 130.15.12, obaja hostitelia sú v rovnakej podsieti.

Počítač v skutočnosti vykonáva logickú operáciu AND medzi maskou a každou z adries IP. Výsledkom je, že nuly masky podsiete vyčistia hostiteľskú časť adresy a ponechajú iba časti siete a podsiete.

V tomto príklade je smerovanie rovno. To znamená, že datagram musí byť umiestnený v rámci a prenesený priamo do cieľa lokálnej siete, ako je znázornené na obr. 6.3.

Ryža. 6.3. Rámovanie a prenos datagramov

Cieľová adresa umiestnená v hlavičke rámca musí byť fyzickou adresou cieľového systému. Na zistenie existencie záznamu pre fyzickú adresu 130.15.12.22 sa kontroluje tabuľka protokolu ARP. Ak v tabuľke nie je požadovaný záznam, na jeho vytvorenie sa použije protokol ARP.

6.5 Hostiteľ v tabuľke smerovania IP

Predpokladajme, že chceme odoslať údaje:

Od: 130.15.12.131

Rýchla kontrola maska ​​podsiete označuje cieľový systém nepatrí lokálna podsieť. V tomto prípade musí IP odkazovať na lokálnu smerovaciu tabuľku.

Smerovacia tabuľka hostiteľa je zvyčajne veľmi jednoduchá. Na obr. Obrázok 6.4 zobrazuje lokálnu sieť, ktorá je pripojená k vzdialeným miestam prostredníctvom jedného smerovača. Ak sa cieľ nenachádza v lokálnej sieti, hostiteľ nemá inú možnosť, ako kontaktovať smerovač.

Ryža. 6.4. Presmerovanie prevádzky cez predvolený smerovač

Každý stolný počítač alebo hostiteľ LAN má smerovaciu tabuľku, ktorá hovorí IP, ako smerovať datagramy do systémov, ktoré nie sú pripojené k LAN. Ak chcete zadať cestu k vzdialenému umiestneniu, táto tabuľka potrebuje jednu položku (pre predvolené smerovanie):

predvolená hodnota 130.15.12.1

Inými slovami, posielať akékoľvek nemiestne datagramy do predvoleného smerovača s IP adresou 130.15.12.1(všimnite si, že cieľová adresa 0.0.0.0 sa v smerovacej tabuľke používa ako predvolená).

6.6 Smerovanie ďalším zásahom

Aby bola hostiteľská smerovacia tabuľka jednoduchá, IP nemusí analyzovať celú cestu k cieľu. Musíte len zistiť ďalší zásah(ďalší skok sa niekedy prekladá ako ďalšia sekcia. - Poznámka. pruh.) a pošlite tam datagram.

Ak chcete odoslať datagram do rozhrania smerovača 130.15.12.1, musí byť umiestnený v rámci, ktorého hlavička obsahuje fyzickú adresu sieťový adaptér tento router.

Keď smerovač prijme rámec, odstráni hlavičku a upútavku rámca a preskúma hlavičku IP datagramu, aby sa rozhodol, kam by mal byť smerovaný ďalej.

6.7 Ďalší príklad hostiteľskej smerovacej tabuľky

Niekedy nie sú tabuľky smerovania hostiteľov také jednoduché. Zvážte napríklad dva smerovače v podsieti 128.121.50.0 (pozri obrázok 6.5). Druhý smerovač spravuje malú lokálnu sieť s niekoľkými pracovnými stanicami.

Ryža. 6.5. Výber smerovača

router tiger spravuje lokálnu sieť a pomocou príkazu je možné zobraziť jej smerovaciu tabuľku netstat -nr. Výstup používa výraz brána - brána, ale nie router - router. (Iné počítače môžu tabuľku zobraziť v mierne odlišnom formáte. Bude obsahovať podobné, ale nie identické informácie. Niektoré systémy môžu napríklad zobraziť stĺpec s informáciami o vzdialenosti do ďalšieho cieľa.)

Príznaky cieľovej brány Refcnt Use Interface

127.0.0.1 127.0.0.1 UH 6 62806 lo0

Predvolená hodnota 128.121.50.50 UG 62 2999087 le0

128.121.54.0 128.121.50.2 UG 0 0 le0

128.121.50.0 128.121.50.145 U 33 1406799 le0

tím netstat zobrazuje informácie o tom, kam a ako bude smerovať premávka tiger.

■ Prvým cieľom v tabuľke je prstencový adresa 127.0.0.1, ktorá slúži ako označenie pre komunikáciu medzi klientmi a servermi v rámci systému tiger.

■ Nahrávanie predvolená sa používa na vykonanie smerovania do ľubovoľného cieľa, ktorý nie je uvedený v tabuľke. Prevádzka by mala smerovať do rozhrania smerovača na adrese IP 128.121.50.50.

■ Datagramy do ľubovoľného systému v podsieti 128.121.54.0 musia smerovať do rozhrania smerovača s adresou IP 128.121.50.2.

■ Posledný záznam neposkytuje nové informácie pre smerovanie, ale poskytuje zaujímavé štatistiky o miestnej premávke. Ak chcete nasmerovať prevádzku do akéhokoľvek systému v podsieti 128.121.50.0, musíte ju nasmerovať na 128.121.50.145. Zároveň je 128.121.50.145 jej vlastnou adresou tiger a 128.121.50.0 je vaša vlastná adresa lokálnej siete tiger.

Tím netstat vyvedie ďalší zaujímavé informácie:

■ Vlajky(Vlajky) informujú o tom, či je trasa použiteľná a či ďalší prístup bude hostiteľ (H) alebo brána (G).

■ REFcnt sleduje aktuálny počet aktívnych použití trasy.

■ Stĺpec použitie počíta počet datagramov, ktoré boli odoslané po trase (od poslednej inicializácie).

■ Rozhranie lo0 je logické rozhranie pre kruhovú prevádzku. Všetka externá prevádzka prechádza cez jedno rozhranie Ethernet - le0.

Všimnite si, že zahrnutie lokálnej podsiete 128.121.50.0 do správy odhalilo, že prevádzka odosielaná smerom von bola dvakrát väčšia ako prevádzka smerovaná do systémov LAN.

6.8 Pravidlo vyhľadávania v smerovacej tabuľke

Každá položka v smerovacej tabuľke poskytuje informácie o smerovaní do konkrétneho cieľa, ktorým môže byť konkrétny hostiteľ, sieť, supernet alebo predvolená hodnota.

Existuje všeobecné pravidlo pre použitie smerovacej tabuľky v protokole IP, bez ohľadu na umiestnenie tejto tabuľky - na hostiteľovi alebo smerovači. Prvok, ktorý sa má vybrať v tabuľke, musí sa najviac zhodujú Cieľová IP adresa. Inými slovami, keď IP vyhľadá cieľové adresy hostiteľa, koncepčne sa vykonajú nasledujúce akcie:

■ Najprv sa v tabuľke vyhľadá adresa, ktorá sa presne zhoduje s cieľovou IP adresou. Ak sa nájde, tento záznam sa použije na smerovanie premávky.

■ Ak takáto adresa neexistuje, v tabuľke sa vyhľadá záznam pre podsieť cieľového systému.

■ Ak takáto adresa neexistuje, v tabuľke sa vyhľadá cieľová sieť.

■ Ak chýba aj táto adresa, v tabuľke sa vyhľadá záznam so zodpovedajúcou predponou smerovania.

■ Ak sa táto adresa nenájde, použije sa predvolený smerovač.

Samozrejme, skutočné vykonanie zahŕňa jednorazové vyhľadanie tabuľky, pričom sa zahodia všetky nájdené, ale menej presné zhody.

6.9 Tabuľky smerovača

Na rozdiel od smerovacích tabuliek hostiteľov, ktoré môžu byť veľmi jednoduché, tabuľky smerovačov často obsahujú oveľa viac informácií. Smerovač má dve alebo viac rozhraní a každý datagram sa musí prenášať cez príslušné rozhranie. Smerovač môže potrebovať záznamy o ďalšom prístupe pre mnoho rôznych sietí a podsietí (pozri obrázok 6.6).

Ryža. 6.6. Smerovanie do mnohých destinácií

6.10 Smerovacia tabuľka pobočky

Niektoré smerovače majú veľmi jednoduché smerovacie tabuľky. Napríklad smerovač pobočky (pozri obrázok 6.7) smeruje prevádzku z hlavnej kancelárie do miestnych sietí a presmeruje všetku odchádzajúcu prevádzku cez regionálnu sieť do hlavnej kancelárie spoločnosti.

Ryža. 6.7. Smerovanie v pobočke firmy

Tento router má dve rozhrania:

Prvá položka popisuje iba priame pripojenie k lokálne pripojenej podsieti 130.15.40.0. dosiahnutá podsieť priamo prostredníctvom vlastného rozhrania.

Druhá položka určuje predvolenú cestu do zvyšku siete. Smerovač pre ďalší prístup - 130.15.201.1 - je dosiahnuteľný cez rozhranie 2. Hlavná kancelária spoločnosti je dosiahnutá nepriamy cestou, cez smerovač ďalšieho zásahu. Obe cesty boli zadané ručne.

6.11 Operácie globálneho smerovania

Zatiaľ sme zvažovali len výber jediného smeru do cieľa. Obrázok 6.8 vysvetľuje kroky pre globálne smerovanie v IP. Ak TCP alebo UDP hostiteľa A chce poslať údaje svojmu partnerovi na hostiteľovi B, pošle tieto údaje na IP, za ktorým nasleduje IP adresa cieľového hostiteľa. IP pridá hlavičku obsahujúcu cieľovú IP adresu pre dáta.

■ IP hostiteľa A skúma cieľovú adresu, aby zistila, či sa nachádza v lokálnej podsieti. Ak nie, IP vyhľadá smerovaciu tabuľku.

■ Z tabuľky môžete vidieť, že ďalším prístupom je smerovač X. Datagram bude orámovaný a hlavička bude obsahovať fyzickú adresu siete LAN pre smerovač X.

■ Keď datagram dorazí do smerovača X, jeho orámovanie sa odstráni. IP smerovača X porovnáva cieľovú IP adresu so všetkými jej adresami (podľa masky podsiete) a kontroluje, či sa cieľ nachádza v lokálne pripojenej podsieti.

Ryža. 6.8. Globálne smerovanie

■ Ak nie, IP vyhľadá smerovaciu tabuľku. Ďalším zásahom bude router Y, kam bude datagram odoslaný po jeho zarámovaní novým rámcom.

■ Keď datagram dorazí do smerovača Y, rámovanie sa odstráni. IP protokol smerovača Y porovná cieľovú IP adresu so všetkými jej adresami (podľa masky podsiete) a skontroluje, či sa cieľ nachádza v lokálne pripojenej podsieti. V našom príklade bude vyhľadávanie úspešné a datagram sa odošle hostiteľovi B.

Trasa z hostiteľa A do hostiteľa B obsahovala tri zásahy (nohy): A-X, X-Y a Y-B.

6.12 Možnosti IP

IP má niekoľko funkcií, vďaka ktorým je protokol flexibilný a vhodný pre rôzne prostredia. Okrem iného treba spomenúť adaptívne smerovanie(adaptívne smerovanie), ako aj fragmentácia a opätovné zostavenie datagramu(fragmentácia a opätovné zostavenie datagramu).

6.12.1 Adaptívne smerovanie

Smerovanie datagramov adaptívny svojou povahou. Najlepšia možnosť pre ďalší zásah v ktoromkoľvek zo zariadení sa vykoná prehľadaním smerovacej tabuľky aktuálneho sieťového uzla. Položky smerovacej tabuľky sa môžu časom meniť, aby odrážali aktuálny stav siete.

Ak je jedno z prepojení (pozri obrázok 6.9) prerušené, datagram sa môže prepnúť na inú cestu (ak je k dispozícii).

Ryža. 6.9. Adaptívne smerovanie

Zmena topológie siete spôsobí automatické presmerovanie datagramu po inej trase. Adaptívne smerovanie sa vyznačuje flexibilitou a spoľahlivosťou.

Na druhej strane hlavička IP môže obsahovať presnú cestu, ako sa dostať do cieľa. To umožňuje, aby bola dôležitá prevádzka smerovaná cez zabezpečenú sieťovú cestu.

6.12.2 MTU, fragmentácia a opätovná montáž

Predtým, ako datagram prejde cez sieť do ďalšej časti zásahu, je zapuzdrený v hlavičke (hlavičkách) druhej vrstvy, ktorú vyžaduje sieťová technológia (pozri obrázok 6.10). Napríklad na prechod cez sieť 802.3 alebo 802.5 sa pridá hlavička LLC, podhlavička SNAP, hlavička MAC a koncová časť MAC.

Ryža. 6.10. Formát posielania rámcov LAN

Ako je uvedené v kapitole 4, každá technológia je lokálna resp globálnej siete má svoje limity na dĺžku rámu. Datagram sa musí zmestiť do rámca, a preto jeho maximálna dĺžka obmedzí veľkosť datagramu odosielaného cez médium.

Maximálna dĺžka datagramu pre konkrétne médium sa vypočíta ako rozdiel medzi maximálnou veľkosťou rámca, dĺžkou záhlavia rámca, dĺžkou koncovej časti rámca a veľkosťou záhlavia vrstvy dátového spojenia:

Maximálna veľkosť frame - dĺžka záhlavia rámca - dĺžka koncovej časti rámca - veľkosť záhlavia dátovej vrstvy

Maximálna možná dĺžka datagramu na danom médiu je tzv maximálny špedičný prvok(Maximálna prenosová jednotka - MTU). Napríklad pre DIX Ethernet je hodnota MTU 1500 oktetov, pre 802,3 - 1492 oktetov, pre FDDI - 4352, pre SMDS - 9180 oktetov.

IN veľké siete Na internete nemusí zdrojový hostiteľ poznať veľkosť akýchkoľvek obmedzení pozdĺž cesty datagramu. Čo sa stane, ak hostiteľ odošle datagram príliš veľký pre jednu z medziľahlých sietí?

Keď sa takýto datagram dostane k smerovaču pripojenému k medziľahlej sieti, IP vyrieši problém s veľkosťou datagramu jeho rozdelením na niekoľko malých úlomky. Cieľový hostiteľ potom bude musieť zhromaždiť všetky prijaté rámce a obnoviť pôvodný datagram.

Fragmentácia sa najčastejšie vykonáva v smerovačoch, avšak aplikácie UDP môžu rozdeliť dlhú správu na fragmenty datagramu naraz na zdrojovom hostiteľovi.

6.13 Mechanizmy protokolu IP

Pozrime sa bližšie na charakteristiku protokolu IP verzie 4 vrátane formátových prvkov tohto protokolu – formátu hlavičky IP a pravidiel kontroly datagramu odosielaného cez sieť. IP verzia 6 je popísaná v kapitole 22 (IP verzia 5 neexistuje).

6.13.1 Hlavička datagramu

Hlavička datagramu organizovaná ako 5 alebo viac 32-bitových slová. Maximálna dĺžka hlavičky je 15 slov (tj 60 oktetov), ​​ale v praxi má väčšina hlavičiek datagramov minimálnu dĺžku 5 slov (20 oktetov).

Polia hlavičky sú znázornené na obr. 6.11. Sú štruktúrované ako sled slov. Všimnite si, že bity slov sú očíslované od 0 do 31.

Ryža. 6.11. Formát datagramu protokolu IP

Najdôležitejšie polia hlavičky sú: Cieľová IP adresa(cieľová IP adresa), Zdrojová IP adresa(zdrojová IP adresa) a Protokol(protokol).

Cieľová IP adresa umožňuje smerovanie datagramu. Akonáhle dosiahne svoj cieľ, pole protokol umožňuje jeho doručenie požadovanej službe, ako je TCP alebo UDP. Okrem TCP a UDP existuje niekoľko ďalších protokolov, ktoré môžu odosielať a prijímať datagramy. Organizácia IANA je zodpovedná za koordináciu priraďovania hodnôt k parametrom TCP/IP vrátane hodnôt v protokol. Niektoré hodnoty v tomto poli majú licencovaný význam špecifický pre výrobcu.

Tabuľka 6.1 zobrazuje najčastejšie hodnoty z poľa protokol.

Tabuľka 6.1 Konvenčné čísla z poľa protokolu hlavičky IP

číslo	názov	Protokol	Popis
1	ICMP		Prenáša chybové hlásenia a podporuje samostatné sieťové nástroje
2	IGMP	Internet Group Management Protocol	Poskytuje skupiny pre multicasting
6	TCP	Protokol riadenia prenosu	Podáva relácie
8	EGP	Protokol vonkajšej brány	Starší protokol na smerovanie v externej sieti
17	UDP	Protokol užívateľského datagramu	Slúži na doručovanie nezávislých blokov údajov
88	IGRP	Smerovací protokol vnútornej brány	Umožňuje výmenu smerovacích informácií medzi smerovačmi Cisco

6.13.3 Verzia, dĺžka hlavičky a dĺžka datagramu

V súčasnosti sa používa IP verzia 4 ("Next Generation" verzia číslo 6).

Dĺžka hlavičky sa meria v 32-bitových slovách. Ak nepotrebujete ďalšie možnosti, môžete obmedziť dĺžku hlavičky na 5 slov (tj 20 oktetov). Ak je zahrnutá jedna alebo viac voliteľných možností, môže byť potrebné vyplniť koniec hlavičky úvodnými nulami až do 32-bitovej hranice slova.

Lúka dĺžka datagramu určuje veľkosť datagramu v oktetoch. Táto hodnota zahŕňa hlavičku aj údajovú časť datagramu. Toto 16-bitové pole môže obsahovať hodnoty až do 2 16 -1 oktetu = 65535 oktetov.

Sieťová technológia nie je jediným dôvodom obmedzenia veľkosti datagramu. Rôzne typy počítačov, ktoré podporujú IP, majú rôzne limity súvisiace s veľkosťou použitej vyrovnávacej pamäte sieťová prevádzka(Štandard IP vyžaduje, aby všetci hostitelia boli schopní prijímať datagramy s veľkosťou aspoň 576 oktetov).

6.13.4 Priorita a typ služby

Pôvodným sponzorom balíka protokolov TCP/IP bolo americké ministerstvo obrany, pre ktoré bola priorita datagramov dôležitá. Mimo armádu a vládne organizácie sa priority málo využívajú. Prioritou sú 3 bity poskytujúce 8 rôznych úrovní.

Štandard IP nešpecifikuje, čo robiť s prioritnými bitmi. Pôvodne boli určené na nastavenie parametrov pre podsiete, ktorými by datagram prešiel pri ďalšom prístupe. Napríklad protokol Token-Ring je riadený na základe prioritných bitov. V tomto prípade musí IP mapovať prioritné bity do príslušných vrstiev token-ringu.

Typ služby(Type of Service - TOS) obsahuje bity, ktoré určujú informácie o kvalite služby, ktoré môžu ovplyvniť spracovanie datagramov. Napríklad, keď routeru dôjde pamäť, je nútený odmietnuť niektoré datagramy. Môže brať do úvahy iba datagramy s bitom dôveryhodnosti nastaveným na jednu a datagramy s bitom nulovej dôveryhodnosti vyradiť.

Pozícia priority a typ služby:

bitov	Typ	Popis
0-2	Priorita	Úrovne 0-7
		Úroveň 0 - normálna priorita
		Úroveň 7 – najvyššia priorita
3-6	TOS	Latencia, spoľahlivosť, priepustnosť, náklady alebo bezpečnosť
7	Vyhradené pre budúce použitie

Typ služby definuje (ako je popísané v aktuálnom dokumente Priradené čísla) hodnoty uvedené v tabuľke 6.2. Toto sú vzájomne sa vylučujúce hodnoty – pre každý datagram IP je potrebná iba jedna hodnota TOS. Štandardné Priradené čísla odporúča použiť špecifické hodnoty pre každú aplikáciu. Napríklad pre telnet- minimalizovať latenciu pri kopírovaní súborov - maximalizovať výkon a spoľahlivosť pri doručovaní správ o riadení siete.

Tabuľka 6.2 Hodnoty poľa Typ služby (TOS).

Niektoré smerovače úplne ignorujú typ poľa služby, zatiaľ čo iné ho môžu použiť pri výbere toho, ktorý prenos sa má chrániť pred nedostatkom Náhodný vstup do pamäťe. Očakáva sa, že typ oblasti služieb bude hrať v budúcnosti oveľa väčšiu úlohu. Uvedené v dokumente Priradené čísla hodnoty sú uvedené v tabuľke 6.3.

Protokol	hodnota TOS	Popis
Telnet a iné protokoly na protokolovanie	1000	Minimalizujte latenciu
Kontrolná relácia FTP	1000	Minimalizujte latenciu
Relácia FTP cez prenos dát	0100
TFTP	1000	Minimalizujte latenciu
Fáza príkazov SMTP	1000	Minimalizujte latenciu
Dátová fáza SMTP	0100	Maximalizujte výkon
DNS dotaz na UDP	1000	Minimalizujte latenciu
DNS dotaz na TCP	0000	Bez špeciálneho manažmentu
Mapovanie zón na DNS	0100	Maximalizujte výkon
NNTP	0001	Minimalizujte peňažnú hodnotu
chyby ICMP	0000	Bez špeciálneho manažmentu
Žiadosti ICMP	0000	Zvyčajne 0000, ale niekedy sa posiela s inou hodnotou
ICMP odpovede		Rovnaké ako požiadavka, na ktorú sa generuje odpoveď
Akýkoľvek IGP	0010	Maximalizujte spoľahlivosť
EGP	0000	Bez špeciálneho manažmentu
SNMP	0010	Maximalizujte spoľahlivosť
BOOTP	0000	Bez špeciálneho manažmentu

6.13.5 Pole životnosti

Keď dôjde k zmene topológie v IP internetovom systéme, ako je downlink alebo inicializácia nového smerovača, niektoré datagramy sa môžu stratiť v krátkom časovom období, kým sa nevyberie nový smerovač.

Vážnejšie problémy vznikajú z chýb pri manuálnom zadávaní smerovacích informácií. Takéto chyby môžu spôsobiť stratu datagramu alebo jeho zacyklenie na dlhú dobu.

Pole Time-To-Live (TTL) obmedzuje dobu, počas ktorej je datagram prítomný na internete. TTL nastavuje odosielajúci hostiteľ a znižuje ho každý smerovač, cez ktorý datagram prechádza. Ak datagram nedosiahne svoj cieľ a jeho pole TTL sa stane nulovým, zahodí sa.

Aj keď sa technicky čas životnosti meria v sekundách, v skutočnosti je TTL implementovaný ako jednoduchý počítadlo zásahov, ktorého hodnota sa znižuje (zvyčajne o jeden) v každom smerovači. Môžete zadať väčšie zníženie počítadla pre datagramy, ktoré prechádzajú veľmi pomalými pripojeniami alebo ich prenos trvá dlho.

6.13.6 Hlavička kontrolného súčtu

Kontrolný súčet je v 16-bitovom poli a je vypočítaný z hodnoty zostávajúcich polí hlavičky IP ako súčet všetkých doplnkových 16-bitových slov hlavičky. Pred výpočtom pole kontrolného súčtu obsahuje 0. Kontrolný súčet je potrebné prepočítať, keď sa datagram pohybuje po sieti, pretože pole TTL sa v datagrame mení. Ostatné hodnoty z hlavičky sa tiež môžu zmeniť v dôsledku fragmentácie alebo zapisovania informácií ďalšie polia.

6.14 Fragmentácia

poliach identifikácia(Identifikácia), vlajky(Vlajky) a ofset fragmentov(Fragment Offset) vám umožňujú fragmentovať a obnoviť (zhromaždiť) datagram. Keď IP potrebuje preposlať datagram väčší ako MTU ďalšieho skoku, potom:

1. Najprv sa skontroluje obsah poľa vlajky. Ak je hodnota "Don't Fragment" nastavená na 1, nie je potrebné nič robiť - datagram sa zahodí a prestane existovať.

2. Ak je príznak „Nefragmentovať“ nastavený na 0, potom sa dátové pole rozdelí na samostatné časti podľa MTU nasledujúceho skoku. Výsledné časti sú zarovnané na 8-oktetovej hranici.

3. Každej časti je priradená hlavička IP podobná hlavičke pôvodného datagramu, najmä hodnoty zdroja, cieľa, protokolu a identifikácia. Nasledujúce polia sú však nastavené individuálne pre každú časť:

a. Dĺžka datagramu bude odrážať aktuálnu dĺžku prijatého datagramu.

b. Viac vlajky z poľa vlajky nastavte na 1 pre všetky časti okrem poslednej.

c. Lúka ofset fragmentov bude indikovať polohu prijatej časti vzhľadom na začiatok pôvodného datagramu. Počiatočná pozícia sa berie ako 0. Ofset fragmentu sa rovná skutočnému offsetu vydelenému 8.

d. Každý fragment má svoj vlastný kontrolný súčet.

Teraz je čas pozrieť sa bližšie na polia vo fragmentácii datagramov.

6.14.1 Identifikačné pole

Lúka identifikácia obsahuje 16-bitové číslo, ktoré pomáha cieľovému hostiteľovi rozpoznať fragment datagramu počas opätovného zostavovania.

6.14.2 Pole s príznakmi

Lúka vlajky obsahuje tri bity:

Bit 0 je rezervovaný, ale musí byť nastavený na 0. Odosielateľ MÔŽE nastaviť nasledujúci bit na 1 a datagram nemôže byť fragmentovaný. Ak nemôže byť doručený bez fragmentácie a fragmentačný bit je 1, potom sa datagram zahodí a správa sa odošle odosielateľovi.

Bit 2 je nastavený na 0 pre poslednú alebo iba časť datagramu. Bit 2 nastavený na 1 znamená, že datagram je fragmentovaný a má nasledujúce časti.

6.14.3 Fragmentové offsetové pole

Fragmentačný blok(fragment block) je 8 oktetový údaj. Číslo v krabici ofset fragmentov(Fragment Offset) označuje veľkosť ofsetu tohto fragmentu (vzhľadom na začiatok datagramu) v jednotkách fragmentačných blokov. Toto pole má dĺžku 13 bitov (tj posun môže byť od 0 do 8192 blokov blokov - alebo od 0 do 65528 oktetov). Predpokladajme, že smerovač rozdelí datagram (s identifikátorom 348) s 3 000 bajtmi údajov na tri datagramy s veľkosťou 1 000 bajtov. Každý fragment bude obsahovať vlastnú hlavičku a 1000 bajtov údajov (125 blokov fragmentov). Obsah poľa identifikácia, vlajky A posuny fragmentov bude nasledovný:

Keď je datagram doručený bez fragmentácie, hodnoty polí budú nasledovné:

Cieľový hostiteľ, ktorý prijal datagram označený ako "Posledný" a má offset 0, vie, že nie je fragmentovaný.

6.14.4 Zostavenie fragmentovaného datagramu

Opätovné zostavenie fragmentovaného datagramu vykonáva cieľový hostiteľ. Jednotlivé časti takéhoto datagramu môžu prísť v ľubovoľnom poradí. Keď prvý fragment dorazí na miesto určenia, IP pridelí určitú oblasť pamäte na následné opätovné zostavenie celého datagramu. Lúka ofset fragmentov ukazuje na bajtovú hranicu pre prijaté fragmentové dáta.

Zhodné podľa polí identifikácia, zdrojová IP adresa, cieľová IP adresa A protokolúlomky sa skladajú pri príchode. V protokole IP je však malá chyba: prijímajúci hostiteľ nemôže poznať celkovú dĺžku datagramu, kým neprijme posledný fragment. Lúka Celková dĺžka(Celková dĺžka) obsahuje iba informácie o daný fragment, nie celkovú dĺžku datagramu.

Prijímací systém teda musí byť schopný presne predvídať, koľko vyrovnávacieho priestoru má vyhradiť pre prijatý datagram. Vývojári tento problém riešia. rôzne cesty. Niektoré postupne prideľujú malé časti pamäte pre vyrovnávaciu pamäť, iné prideľujú jednu veľkú vyrovnávaciu pamäť naraz.

V každom prípade pri realizácii nevyhnutné obsluhuje prichádzajúci datagram s celkovou dĺžkou najmenej 576 oktetov. Alebo presnejšie, systém musí byť schopný spracovať datagramy s celkovou veľkosťou aspoň MTU rozhrania, na ktoré datagramy prichádzajú.

6.14.5 Časový limit zostavenia datagramu

Zvážte nasledujúci sled udalostí:

■ Odosiela sa datagram.

■ Proces, ktorý ho odoslal, zlyhá.

■ Datagram je pri prenose fragmentovaný.

■ Jeden z úlomkov sa cestou stratí.

Ak sa odoslaný fragment stratí, prijímajúci hostiteľ MUSÍ počkať, kým sa fragment znova odošle. Zároveň je to samozrejme potrebné obmedziť čakaciu dobu. Keď uplynie časový limit zostavenia, cieľový hostiteľ zahodí už prijaté fragmenty a odošle zdroju chybovú správu. Hodnota časového limitu zostavy je zvyčajne konfigurovateľná. Jeho hodnotu sa odporúča nastaviť v rozsahu od 60 do 120 s.

6.14.6 Fragmentovať alebo nefragmentovať

Vzhľadom na všetky problémy podpory fragmentácie môžeme povedať, že vedie k zníženiu výkonu. Preto sa mnohí programátori snažia starostlivo navrhovať aplikácie tak, aby boli generované datagramy dostatočne malé a pri prenose neboli fragmentované.

V kapitole 7 sa pozrieme na protokol zisťovania MTU, aby sme sa vyhli fragmentácii datagramov a použili najväčšiu veľkosť MTU pri preposielaní informácií.

6.15 Prezeranie štatistík IP

O tom, ako IP funguje, sa môžete dozvedieť z pomerne približných štatistických správ. Tím netstat -s zobrazuje obsah počítadiel pre najdôležitejšie udalosti v IP. Nasledujúca správa je prijatá na server tigger.jvnc.net, ktorý je dostupný hostiteľom na celom internete. Na to odpovieme v správe namiesto presnejšieho termínu "datagram" používa sa termín "plastový sáčok"(balík).

Celkovo bolo prijatých 13572051 paketov

0 s veľkosťou menšou ako minimum

8 s veľkosťou údajov< data length

0 dĺžka hlavičky< data size

0 s dĺžkou údajov< header length

0 vypadnutých fragmentov (duplikácia alebo nedostatok miesta)

Po uplynutí časového limitu vypadli 2 fragmenty

Počas vykazovaného obdobia sa nevyskytol ani jeden datagram so zlým kontrolným súčtom (kontrolné súčty) a tiger nevyradil žiadne datagramy pre nedostatok pamäte. Akceptovaných bolo 90 fragmentov, čo je 0,00066 % z celkového množstva informácií. Časový limit dvoch fragmentov vypršal a pri pokuse o smerovanie zo zdroja cez tiger.

6.16 Možnosti

Pre jednu alebo viac voliteľných možností je v hlavičke IP k dispozícii 40 špeciálnych oktetov. Varianty datagramov si vyberajú aplikácie, ktoré ich posielajú. Používajú sa veľmi zriedkavo. Zoznam možností obsahuje:

■ Striktná zdrojová cesta

■ Trasa voľného zdroja

■ Záznam trasy

■ Časová pečiatka (časová pečiatka)

■ Základná bezpečnosť ministerstva obrany

■ Ministerstvo obrany Rozšírená bezpečnosť

■ Bez prevádzky

■ Koniec zoznamu možností (výplň) – koniec zoznamu možností (zástupný symbol)

Bezpečnostné možnosti využíva ministerstvo obrany a niektoré vládne agentúry. Bolo navrhnutých aj niekoľko ďalších možností úplný zoznam varianty a ich aktuálny stav nájdete v najnovších vydaniach pridelené číslo A Internetový oficiálny protokolový štandard).

Existujú dva zdroje: Prísna zdrojová cesta, definovanie plná cesta do cieľa a Voľná ​​zdrojová trasa, identifikácia kontrolných bodov na trase (míľniky). Medzi kontrolnými bodmi je možné použiť akúkoľvek trasu.

Striktné zdrojové trasy sa niekedy používajú na zlepšenie bezpečnosti údajov. Ako však uvidíme neskôr, tento zdroj využívajú aj hackeri na prienik do systémov. počítačová bezpečnosť.

Niekedy sa táto možnosť používa pri testovaní sietí. Loose Source Route je navrhnutá tak, aby pomohla pri smerovaní na vzdialené miesto.

Mechanizmy oboch možností sú podobné. Jediný rozdiel je v tom, že môžete navštíviť cestu Strict Source Route iba systémy z vopred definovaného zoznamu.

6.16.2 Spiatočná cesta

Ak sa použije smerovanie zdroja, vrátená prevádzka z cieľa do zdroja musí sledovať rovnakú cestu (sada smerovačov), ale v opačnom poradí.

To vyvoláva jeden problém: z hľadiska zdrojového a cieľového systému sú adresy smerovačov odlišné. Na obr. Obrázok 6.12 zobrazuje cestu medzi dvoma hostiteľmi. Trasa z hostiteľa A do hostiteľa B zahŕňa prechod cez smerovače, ktorých adresy pre hostiteľa A sú 130.132.9.29 a 130.132.4.11. Cesta od hostiteľa B k hostiteľovi A prechádza cez smerovače s IP adresami známymi hostiteľovi B ako 128.36.5.2 a 130.132.4.16. Adresy rozhrania smerovača sa líšia, pretože sú pripojené k rôznym podsieťam.

Ryža. 6.12. Cesty z pohľadu hostiteľov A a B

Riešenie tohto problému je jednoduché: pri každej návšteve smerovača sa v poli nahradí vstupná adresa zdrojová trasa na výstupnú adresu a cieľový systém dostane už výsledný zoznam v opačnom poradí a môže použiť smerovanie zo zdroja na presun späť.

6.16.3 Popis trasy

Možno si myslíte, že na smerovanie zo zdroja stačí vytvoriť zoznam smerovačov medzi zdroj a cieľ. Avšak nie je. Tabuľka 6.4 zobrazuje obsah polí Zdrojové IP adresy(zdrojová IP adresa), Cieľové IP adresy(Cieľová IP adresa) a polia smerovanie zdroja(Zdrojová trasa) na každom kroku pozdĺž cesty:

■ V kroku 1 pole Cieľové IP adresy obsahuje adresu prvého smerovača. Ukazovateľ z poľa zdrojová trasa definuje ďalší zásah (v tabuľke tučným písmom).

■ V kroku 2 pole Cieľové IP adresy obsahuje adresu druhého smerovača. Ukazovateľ z poľa zdrojová trasa určuje ďalší zásah. V našom príklade je to skutočný cieľ datagramu.

■ V kroku 3 dosiahne datagram svoj cieľ. Jej polia Zdrojové IP adresy A destinácia obsahujú správne hodnoty, a v zdrojová trasa sú uvedené všetky odovzdané smerovače.

Tabuľka 6.4 Smerovanie zdroja

Krok	Zdrojová IP adresa	Cieľová IP adresa	Pole SourceRoute
1	130.132.9.44	130.132.9.29	130.132.4.11 128.36.5.76
2	130.132.9.44	130.132.4.11	130.132.4.16 128.36.5.76
3	130.132.9.44	128.36.5.76	130.132.4.16 128.36.5.2

Smerovanie zdroja sa stalo súčasťou hackerského arzenálu hackerských nástrojov. Touto metódou je možné preniknúť z internetu do sietí, ktorých správcom nezáleží na bezpečnosti.

Smerovače, ktoré filtrujú prevádzku do organizácie, musia byť schopné blokovať prevádzku smerovanú zdrojom alebo kontrolovať zdrojová trasa za súlad reálny miesto určenia datagramu.

Ďalší problém nastáva pri multicast hostiteľoch pripojených k jednej alebo viacerým podsieťam. Faktom je, že takíto hostitelia môžu prenášať zdrojovo smerované datagramy, čím sa otvára prístup k sieťovej prevádzke zo „zadných vrátok“. Hostitelia multicast musia mať tiež možnosť zakázať smerovanie zdroja.

6.16.5 Zaznamenávanie trasy

Lúka položky cesty(Record Route) obsahuje zoznam IP adries smerovačov, ktorými datagram prechádza. Každý smerovač, ktorý sa na ceste stretne, sa pokúsi pridať svoju výstupnú adresu do takéhoto zoznamu.

Dĺžka zoznamu je však nastavená odosielateľom a nemusí byť dostatok miesta na zaznamenanie všetkých adries pozdĺž cesty datagramu. V tomto prípade router jednoducho prepošle datagram bez pridania vlastnej adresy.

6.16.6 Časová pečiatka

Existujú tri formáty poľa časová značka(Časová pečiatka), ktorá môže obsahovať:

■ Zoznam 32-bitových časových pečiatok

■ Zoznam adries IP a ich zodpovedajúcich párov časových pečiatok.

■ Zoznam adries vopred vybratých v zdroji, za ktorým nasleduje priestor pre časovú pečiatku (hostitelia tam zapíšu časové pečiatky iba vtedy, keď sa ich adresy zhodujú s adresami v zozname)

V prvom a druhom prípade nemusí byť dostatok miesta na nahrávanie. Potom sa vytvorí podpole pretečenia na sčítanie uzlov, ktorým sa nepodarilo zapísať svoje časové pečiatky.

6.16.7 Základná a zvýšená bezpečnosť ministerstva obrany

Možnosť základné zabezpečenie (Basic Security) sa používa na overenie, či je zdroj oprávnený odosielať datagram, smerovač je oprávnený vysielať a prijímač je oprávnený ho prijímať.

Parameter Základné zabezpečenie pozostáva z úrovní klasifikácie od Unclassified (nie tajné) po prísne tajné (prísne tajné) a príznaky identifikácie autora. Tieto úrovne definujú pravidlá pre datagram. Autorstvo bolo pridelené niekoľkým organizáciám, ako je Národná bezpečnostná agentúra USA, CIA a ministerstvo energetiky.

Datagram so základným zabezpečením môže obsahovať aj pole Rozšírená bezpečnosť. Pre tieto polia existuje niekoľko rôznych podformátov, ktoré spĺňajú požiadavky rôznych držiteľov autorských práv.

Smerovač alebo hostiteľ musí zničiť informácie, na ktoré nemá autorské práva. Bezpečnostné systémy sú nakonfigurované s rôznymi úrovňami klasifikácie a môžu odosielať a prijímať priradenia, ak je to povolené. Upozorňujeme, že mnohé komerčné produkty tieto funkcie nepodporujú.

6.16.8 Koniec zoznamu možností a žiadne operácie

Možnosť "žiadne operácie"(No Operation) sa používa na vyplnenie medzier medzi variantmi datagramov. Používa sa napríklad na zarovnanie nasledujúceho variantu na 16-bitovú alebo 32-bitovú hranicu.

Koniec zoznamu možností(Koniec zoznamu možností) sa používa na vyplnenie polí možností až do 32-bitovej hranice.

6.16.9 Kódovanie variantov

Existujú dva jednobajtové varianty zakódované takto:

Žiadna operácia 00000001

Koniec zoznamu možností 00000000

Zvyšné možnosti sú dané niekoľkými bitmi. Každý začína oktetom typu a oktet dĺžka.

Pri zvažovaných možnostiach vyvstáva nasledujúca otázka: je potrebné ich skopírovať do hlavičiek datagramov prijatých počas fragmentácie? Kopírovanie sa vykonáva pre Bezpečnosť, prísna trasa zdroja A Uvoľnená zdrojová trasa. poliach Zaznamenať trasu A Časová značka sa skopírujú iba do prvého fragmentu datagramu.

Typový oktet sa delí na:

Tabuľka 6.5 zobrazuje hodnoty oktetu typu a jeho rozdelenie do polí Copy (copy), Class (class) a Option Number (číslo možnosti) pre každú štandardnú možnosť.

Tabuľka 6.5 Polia Copy, Class a Option Number

Význam	Kopírovať	trieda	číslo	názov
0	0	0	0	Koniec zoznamu možností
1	0	0	1	Žiadna operácia
137	1	0	9	Prísna zdrojová cesta
131	1	0	3	Uvoľnená zdrojová trasa
7	0	0	7	Zaznamenať trasu
68	0	2	4	Časová značka
130	1	0	2	bezpečnosť
133	1	0	5	Rozšírená bezpečnosť

Formáty najbežnejších variantných polí sú znázornené na obr. 6.13.

Ryža. 6.13. Variantné formáty polí

Možnosť Prísna zdrojová cesta(presná trasa zo zdroja) obsahuje ukazovatele na zoznam adries. Ukazovateľ určuje polohu ďalšej adresy, ktorá sa má spracovať. Na začiatku má ukazovateľ hodnotu 4, ktorá sa pri každom zásahu zvýši o 4.

Možnosť Uvoľnená zdrojová trasa(ľubovoľná cesta zo zdroja) obsahuje ukazovatele na zoznam adries. Počiatočná poloha ukazovateľ, ako v predchádzajúcom prípade, tu 4 a zvýšený o 4 pri dosiahnutí každej z adries v zozname.

6.16.12 Kódovanie trasy záznamu

Možnosť Zaznamenať trasu(zápis trasy) obsahuje ukazovatele a miesto na zapisovanie adries. Na začiatku má ukazovateľ hodnotu 4 a adresný priestor je prázdny.

Po dosiahnutí každého smerovača sa jeho adresa zapíše do ukazovateľa a hodnota ukazovateľa sa zvýši o 4. Keď sa zaberie všetok priestor určený pre záznam, datagram bude pokračovať do cieľa bez zapisovania ďalších adries.

6.16.13 Kódovanie časovej pečiatky

Možnosť Časová značka(časová pečiatka) obsahuje ukazovateľ, podpole pretečenia a podpole príznaku. Podpole príznak špecifikuje jeden z troch možných formátov časovej pečiatky.

Ak je podpole príznaku 0, potom sa pri každom zásahu zapíše časová značka na pridelené miesto a hodnota ukazovateľa sa zvýši o 4. Keď je vopred pridelený priestor plný, podpole pretečenia sa zvýši a všetky prichádzajúce datagramy sa zahodia.

Ak sa v podpole príznaku nachádza 1, potom pri každom zásahu IP adresy sa na prázdne miesto zapíše časová pečiatka a hodnota ukazovateľa sa zvýši o 8. Keď sa zaplní všetok vopred pridelený priestor, hodnota pretečenia podpole sa zväčší o jednu a záznam časových pečiatok sa zastaví. Predpokladajme, že odosielateľ chce zaznamenať časové pečiatky pre zoznam vopred vybratých uzlov. V tomto prípade je potrebné zadať 3 do poľa príznaku a vyplniť zoznam vybraných internetových adries. Ak je ukazovateľ aktuálne nastavený na adresu smerovača, toto zariadenie vyplní priestor časovej pečiatky a zvýši ukazovateľ o 8.

6.16.14 Kódovanie základných a rozšírených možností zabezpečenia

Hodnoty pre tieto polia stanovujú vojenské a vládne agentúry. Ďalšie informácie možno získať z RFC 1108.

6.17 Príklad hlavičky IP

Na obr. 6.14 ukazuje výsledok analyzátora Sniffer podľa Network General pre hlavičku rámca Ethernet DIX MAC a pre hlavičku IP.

DLC: Rám 14 dorazil o 10:26:10,5797; veľkosť je 61 bajtov

DLC: Destination = Station Sun 076A03, Sun Atlantis

DLC: Zdroj = Stanica Sun 07FD89, Sun Jupiter

IP: Verzia = 4, dĺžka hlavičky = 20 bajtov

IP: .... 0... = normálna priepustnosť

IP: .... .0.. = bežná spoľahlivosť

IP: Time to Live = 30 sekúnd / skoky

IP: Kontrolný súčet hlavičky = 12F4 (správne)

IP: Zdrojová adresa =

IP: Cieľová adresa =

06 00 20 07 6A 03 (fyzická adresa cieľa)

08 00 20 07 FD 89 (fyzická adresa zdroja)

45 00 00 2F (verzia, dĺžka Hdr, Prec/TOS, Celková dĺžka)

11 6A 00 00 (identifikácia, vlajky, ofset fragmentov)

1E 06 12 F4 (Time to Live, Protocol, Header Checksum)

C0 2A FC 01 (zdrojová IP adresa)

C0 2A FC 14 (cieľová adresa IP)

Ryža. 6.14. Interpretácia hlavičiek MAC a IP

Hlavička MAC začína 6-bajtovými fyzickými adresami zdrojového a cieľového systému. Všimnite si, že analyzátor Sniffer nahradí prvé 3 bajty každej fyzickej adresy zodpovedajúcim názvom výrobcu sieťového adaptéra (v našom prípade je to slnko). Pole typu obsahuje kód X"0800, čo znamená: " táto informácia doručiť do IP“.

Na obrázku IP datagram bezprostredne nasleduje po krátkej MAC hlavičke DIX Ethernet. Toto je rámec 802.3 a za MAC hlavičkou je 8-bajtová hlavička LLC s podhlavičkou SNAP.

Veľkosť rámca je 61 bajtov. Táto hodnota zahŕňa 14-bajtovú MAC hlavičku rámca, ale neberie do úvahy 4-bajtovú koncovú MAC časť, takže celý rámec je dlhý 65 bajtov. Rámce Ethernet alebo 802.3 pre médiá na koaxiálnom kábli musia mať dĺžku aspoň 64 bajtov, takže rámec takmer klesol pod povolenú minimálnu veľkosť. Datagram rámca má celkovú dĺžku iba 47 bajtov.

Podobne ako mnohé hlavičky IP, hlavička príkladu neobsahuje žiadne varianty, a preto má dĺžku 20 bajtov. V praxi pole Typ služby má zvyčajne hodnotu 0.

Môžete vidieť, že datagram nie je fragmentom dlhšieho datagramu, pretože pole Odsadenie fragmentov ukladá 0 na označenie začiatku datagramu a druhý príznak je nastavený na 0 na označenie konca datagramu.

Datagram zaznamenal informáciu o 30 zásahoch do poľa TTL. Lúka Protokol je 6, čo znamená doručenie datagramu TCP cieľovému hostiteľovi.

Analyzátor Sniffer preložil zdrojové a cieľové IP adresy do spoločného bodkovaného formátu.

V spodnej časti obrázku sú zobrazené hexadecimálne oktety, ktoré tvoria pôvodnú hlavičku MAC a hlavičku IP. Dané v Sniffer hexadecimálny výstup bol nahradený zodpovedajúcimi, ale jednoduchšími bodkovanými hodnotami.

6.18 Skript na spracovanie datagramov

Aby sme lepšie pochopili, ako IP funguje, pozrime sa na operácie spracovania datagramov v smerovači a cieľovom hostiteľovi. Jednotlivé kroky sú znázornené na obr. 6.15.

Ryža. 6.15. Spracovanie datagramov

Problémy a chyby, ktoré sa vyskytnú, zvyčajne vedú k vyradeniu datagramu a odoslaniu chybovej správy do zdroja. Tieto procesy budú diskutované v kapitole 7 o protokole. Internet Control Message Protocol(ICMP).

6.18.1 Spracovanie v smerovači

Po prijatí datagramu router vykoná sériu kontrol, aby zistil, či sa má datagram zahodiť. Kontrolný súčet hlavičky sa vypočíta a porovná s hodnotou v poli kontrolného súčtu.

Zobrazujú sa polia A protokol identifikovať zmysluplné hodnoty. Znižuje hodnotu z poľa životnosti. Ak je chyba v kontrolnom súčte, parametroch alebo nulovej hodnote doby životnosti, alebo ak router nemá dostatok pamäte na pokračovanie v spracovaní, datagram sa zahodí.

Ďalším krokom je vykonanie bezpečnostnej analýzy prostredníctvom série vopred nakonfigurovaných testov. Smerovač môže napríklad obmedziť prichádzajúcu prevádzku tak, aby bolo dostupných len niekoľko cieľových serverov.

Ďalej router vykoná procedúru smerovania datagramu. Ako je uvedené v hlavičke datagramu, vyberá sa variant presnej alebo ľubovoľnej trasy zo zdroja. Potom, ak je to potrebné a povolené, sa vykoná fragmentácia. Ak datagram nemožno odovzdať bez toho, aby bol fragmentovaný, ale pole Nefragmentovať je nastavené na 1, zahodí sa.

Dostupné možnosti sa spracúvajú. Pre každý datagram alebo jeho fragment musia byť vytvorené upravené hlavičky. Nakoniec sa prepočíta kontrolný súčet hlavičky a datagram sa odošle do systému nasledujúceho prístupu. Toto je najbežnejší scenár spracovania datagramu smerovačom. Niekedy je to však konečný cieľ datagramu. Napríklad požiadavka na informácie o správe siete môže byť zaslaná samotnému smerovaču.

6.18.2 Spracovanie v cieľovom hostiteľovi

Cieľový hostiteľ počíta kontrolná suma, a výsledok sa porovná s príslušným poľom. Skontroluje sa, či cieľová adresa patrí tomuto hostiteľovi. Kontroluje sa aj správnosť polí verzia, dĺžka hlavičky, celková dĺžka A protokol. Datagram sa zahodí pri akejkoľvek chybe alebo keď nie je dostatok vyrovnávacej pamäte na to, aby ho hostiteľ spracoval.

Ak je datagram fragmentovaný, hostiteľ skontroluje štyri polia: identifikácia, zdrojová adresa, cieľová adresa A protokol identifikovať fragmenty s identickými hodnotami (t. j. patriace do rovnakého datagramu). Ďalej sa hodnota z poľa posunutia fragmentu použije na vzájomné umiestnenie fragmentov.

Celý datagram sa odošle príslušnej službe vysoký stupeň, ako napríklad TCP alebo UDP.

Hostiteľ nečaká na kompletné zostavenie datagramu z fragmentov. Keď príde prvý fragment, časovač sa nastaví na lokálne konfigurovateľnú hodnotu (zvyčajne medzi 1 a 2 minútami). Fragmenty datagramu, ktoré sa v tomto čase nezozbierali, sa zahodia.

6.19 Ochranné prostriedky a bezpečnosť

Každý chce z komunikácie vyťažiť maximum, ale obozretný správca siete vždy podnikne kroky na ochranu počítačových zdrojov pred vonkajšími zásahmi, predovšetkým pred hackermi. Smerovače s bezpečnostnými prvkami(smerovač brány firewall; niekedy sa používa doslovný preklad - firewall, t.j. požiarna stena. - Poznámka. pruh.) sa stali najobľúbenejšími zariadeniami v obrannom arzenáli správcu siete.

Bezpečnostné smerovače sú nainštalované na filtrovanie prevádzky, aby bola stránka bezpečná. Ako je znázornené na obr. 6.16 môžu byť takéto smerovače nakonfigurované tak, aby povolili alebo zakázali prevádzku na základe:

■ Zdrojové adresy IP

■ Cieľové adresy IP

■ Protokol

■ Aplikácie

Ryža. 6.16. Router s bezpečnostnými prvkami

Interným používateľom môže byť napríklad povolené odosielať a prijímať správy Email a prístup k externým WWW serverom a externým používateľom len k malej podskupine serverov lokality.

Dodatočnú ochranu poskytuje inteligentný filtrovací hostiteľ s bezpečnostnými funkciami. V niektorých implementáciách sa musia interní používatelia pripojiť k bezpečnostnému nástroju a overiť sa, aby sa mohli pripojiť k vonkajšiemu svetu. Používateľom môžu byť individuálne pridelené privilégiá. Všetka návštevnosť z vonkajšieho sveta bude filtrovaná hostiteľským bezpečnostným nástrojom a môže byť analyzovaná podľa určitých kritérií.

Niektorí zabezpečení hostitelia fungujú ako proxy. Keď interný používateľ požaduje informácie z vonkajšieho sveta, vytvorí sa spojenie so serverom proxy, ktorý prijme informácie a potom ich odovzdá internému používateľovi.

Pre väčšiu bezpečnosť môžu byť lokality nastavené do režimu LAN „demilitarizovanej zóny“ umiestnením bezpečnostných hostiteľov a všetkých interne prístupných aplikačných serverov do siete LAN chránenej filtrovacím smerovačom. Na obr. Obrázok 6.17 zobrazuje takúto zónu LAN, ktorá sa používa na ochranu pred vonkajším narušením.

Ryža. 6.17. Zabezpečenie stránky pomocou DMZ

Použitie bezpečnostného proxy vám umožňuje priradiť osobné IP adresy počítačom stránky (nie sú známe externým používateľom, ktorí majú prístup len k proxy adrese alebo bezpečnostným nástrojom. - Poznámka. pruh.). V tomto prípade by jedine systémy v obvodovej sieti LAN vyžadovali jedinečné verejné adresy.

6.20 Úvahy o výkonnosti IP

Výkon internetu závisí od množstva zdrojov dostupných na hostiteľoch a smerovačoch a od toho, ako efektívne sa využívajú. Tieto zdroje zahŕňajú:

■ Šírka pásma na preposielanie informácií

■ Kapacita vyrovnávacej pamäte

■ Rýchlosť centrálnej procesorovej jednotky (CPU).

Neexistujú žiadne dokonalé protokolové mechanizmy. Návrh protokolu vyžaduje kompromis medzi šírkou možností a efektívnosťou.

6.20.1 Šírka pásma

IP efektívne využíva šírku pásma. Datagramy sú zaradené do frontu na preposielanie na ďalší prístupový bod hneď, ako bude k dispozícii šírka pásma (šírka pásma); tradične budeme používať termín „šírka pásma“, hoci výraz „zdieľanie priepustnosti siete“ je zmysluplnejší. Poznámka. pruh.). Výsledkom je, že sa zabráni plytvaniu rezervovaním šírky pásma pre špecifickú prevádzku alebo čakaním na dopredné potvrdenie.

A čo viac, existujú nové protokoly smerovania IP s viacerými možnosťami: dokážu paralelizovať prevádzku pozdĺž viacerých ciest a dynamicky vyberať smerovače, aby sa zabránilo preťaženiu v určitých častiach cesty datagramu. Použitie takýchto protokolov umožňuje zlepšiť využitie dostupných zdrojov na prenos informácií.

Existuje však mierna réžia kvôli kontrolným správam, ktoré majú ICMP ako jediný zdroj.

V dôsledku toho sa objavia niektoré negatívne vlastnosti. Keď je prevádzka smerovaná z vysokorýchlostnej siete LAN na spojenie bod-bod s nízkou šírkou pásma, datagramy sa začnú hromadiť vo fronte smerovača. Čas doručenia od zdroja k cieľu sa zvyšuje a niektoré datagramy sú vypustené. V tomto prípade je potrebný opakovaný prenos datagramov, čím sa ďalej zvyšuje zaťaženie siete a znižuje sa jej priepustnosť.

Všimnite si tiež, že keď je sieť preťažená, doručovanie datagramov sa spomaľuje a stáva sa menej spoľahlivým. Niektoré veľmi efektívne algoritmy však umožňujú protokolu TCP okamžite reagovať na preťaženie znížením množstva odosielaných údajov a znížením úrovne prenosu.

Tieto algoritmy majú významný vplyv na výkon siete, a preto sa stali neoddeliteľnou súčasťou štandardu TCP (pozri kapitolu 10).

Výrobcovia smerovačov aktívne vytvárajú stále pokročilejšie zariadenia, ktoré dokážu spracovať desiatky tisíc datagramov za sekundu. Ak chcete dosiahnuť vysoký výkon, mali by ste tiež starostlivo zvážiť konfiguráciu siete tak, aby predpokladané maximálne využitie pamäte bolo približne 50 % celkovej vyrovnávacej pamäte.

6.20.2 Použitie vyrovnávacej pamäte

Za jeho doručenie je zodpovedný protokol IP, ktorý prenáša datagram. Pre prípady, keď sa datagram z jedného alebo druhého dôvodu nedostal na miesto určenia, je poskytnutá vyrovnávacia pamäť datagramu, ktorá vám umožní vykonať operáciu prenosu znova. Na druhej strane, cieľová IP hostiteľa musí prideliť určitý priestor vyrovnávacej pamäte na opätovné zostavenie fragmentovaných datagramov.

6.20.3 Zdroje CPU

Spracovanie datagramov nemá za následok veľké zaťaženie centrálnej procesorovej jednotky (CPU). Analýza hlavičky je pomerne jednoduchá. Na spracovanie časových limitov a opakovaných prenosov nie je potrebný žiadny zložitý softvér.

V dôsledku dynamických zmien a nedostatku spojení vyžaduje protokol IP spracovanie smerovacích informácií v každom systéme prístupu. Robí sa to však jednoduchým skenovaním tabuľky, čo je aj pri veľkých stoloch celkom rýchle.

Bezpečnostná analýza vykonávaná smerovačmi spomaľuje spracovanie, najmä ak existuje dlhý zoznam podmienok na kontrolu každého datagramu.

6.21 Získajte viac informácií o multicastoch

Používa sa trieda IP adries multicast broadcasting (pozri kapitolu 5), ktorý umožňuje smerovať datagram zo zdroja do skupiny systémov špecifikovaných jednou z adries triedy D. Technológie a protokoly na podporu multicastingu v aplikáciách (napríklad v konferenciách) sa výrazne zlepšili a rozšírili svoje schopnosti v posledných rokoch.

V tejto časti stručne zhodnotíme niektoré implementácie multicast, ktoré sa v súčasnosti používajú. Najprv však uvádzame fakty:

■ Protokol IGMP poskytuje mechanizmus umožňujúci smerovačom multicast určiť, či hostitelia patria do skupiny multicast. IGMP sa považuje za súčasť IP. Správy IGMP sú prenášané IP datagramami s hodnotou 2 v poli protokolu.

■ multicast router je akýkoľvek systém, ktorý vykonáva špecifický softvér multicast smerovanie, ktoré môže bežať na bežných smerovačoch alebo hostiteľoch nakonfigurovaných na vykonávanie multicastu.

Zvážte scenár hostiteľa multicast:

■ Hostiteľ, ktorý sa chce pripojiť Komu skupina a prijímanie multicastov, začne počúvať na multicastovej adrese pre všetkých hostiteľov (224.0.0.1).

s Ak sa hostiteľ chce pripojiť k určitej skupine, musí to oznámiť všetkým multicastovým smerovačom na lokálnej linke. Aby to urobil, pošle správa-správa IGMP podľa adresy požadovanú skupinu multicast. Pole TTL takejto správy je nastavené na 1 a správa nemôže opustiť lokálnu podsieť.

■ Hostiteľ potom začne počúvať datagramy odoslané na adresu multicast.

■ Okrem toho hostiteľ odpovedá na pravidelné požiadavky od miestnych smerovačov a odpovedá vhodnou správou.

■ Ak chcete opustiť skupinu, hostiteľ jednoducho prestane počúvať adresu skupiny a prestane sa hlásiť skupine.

Popísané kroky hostiteľa sú príliš priamočiare. Smerovanie musí byť o niečo zložitejšie, a preto je v procese zlepšovania. Zvážte akcie v smerovači:

■ Smerovač multicast počúva na všetkých rozhraniach a prijíma správy od hostiteľov. Pre každé z jeho rozhraní sa vytvorí zoznam všetkých skupín multicast, ktoré majú aspoň jedného aktívneho člena v podsieti, ku ktorej sa pristupuje cez tento smerovač.

■ Smerovač musí poslať zoznam adries aktívnych skupín iným smerovačom pre každú z jeho pripojených podsietí.

■ Keďže hostitelia sú dosť tichí, smerovač musí pravidelne kontrolovať miestne systémy, či nie sú členmi určitej skupiny. K tomu z času na čas posiela žiadosť podľa adresy "všetci hostitelia". Každý hostiteľ v skupine bude čakať náhodne dlhý čas. Prvý respondent vo svojej odpovedi uvedie skupinová adresa. Smerovač a všetky systémy v tejto skupine budú počuť túto odpoveď. Keďže router potom vie, že v skupine je aspoň jeden aktívny člen, nie sú potrebné žiadne ďalšie odpovede.

■ Keď smerovač prijme datagram multicast, prepošle ho každej podsieti, ktorá je k nemu pripojená a ktorá má člena tejto skupiny. Smerovač môže tiež poslať datagram do iného smerovača multicast.

Správa IGMP hostiteľa má formát znázornený na obr. 6.18. Hodnota typu 1 definuje dotaz hostiteľského členstva a hodnota 2 definuje zostavu hostiteľského členstva.

Ryža. 6.18. Formát správy IGMP od hostiteľa

Protokol IP je definovaný v RFC 791. Zmeny, doplnky a požiadavky na kompatibilitu sú špecifikované v RFC 1122. RFC 1812 podrobne popisuje požiadavky IP verzie 4 na smerovače a poskytuje podrobnosti o prevádzke takýchto smerovačov.

Možnosti zabezpečenia DoD sú diskutované v RFC 1108. Internetový kontrolný súčet je zahrnutý v RFC 1071, 1141 a 1624. RFC 815 poskytuje efektívne algoritmy na opätovné zostavenie po fragmentácii datagramu na hostiteľovi príjemcu.

RFC 1112 špecifikuje hostiteľské rozšírenia pre IP multicast.

Jedným z najväčších nedostatkov internetového protokolu IPv4 je relatívne malý počet adries, ktoré poskytuje, približne 4,23 miliardy adries, pretože toto číslo sa už nezdá byť také veľké v porovnaní s počtom zariadení pripojených k internetu. Dodnes sa používanie IPv4 darí, keďže sa používajú rôzne technológie na šetrenie používania. sieťové adresy, najmä technológiu NAT (NetworkAddress Translation, preklad sieťových adries), no už teraz je každému jasné, že dni prevádzky IPv4 sa končia, keďže v blízkej budúcnosti sa počíta s umožnením prístupu na internet pre všetky domácnosti. spotrebiče (chladničky, mikrovlnné rúry) na správu týchto zariadení na diaľku, prostredníctvom siete odkiaľkoľvek na svete.

V tejto situácii je prechod na nový formát sieťová adresa sa stáva extrémne ostrovnou. Hoci mnohí odborníci predvídali problém s nedostatkom sieťových adries už začiatkom roku 1990, v tom istom čase začala skupina IETF Internet Design Group pracovať na novej verzii sieťový protokol - IPv6.

Hlavné úlohy, ktoré treba vyriešiť:

• Možnosť prístupu do globálnej siete s miliardami hostiteľov aj pri iracionálnom využívaní adresného priestoru.
• Zmenšenie veľkosti smerovacích tabuliek
• Zjednodušenie protokolu na urýchlenie spracovania smerovacích paketov
• Zvýšte bezpečnosť protokolu
• Zjednodušte prácu s rozosielaním správ špecifikovaním rozsahu odosielania.
• Vyhliadky na ďalší rozvoj protokolu v budúcnosti
• Organizácia kompatibility starého a nového protokolu

Protokol IPv6 bol vyvinutý na konci roku 1992.

protokol IPv6(Internet Protocol version 6) je nová verzia internetového protokolu (IP), vytvorená na riešenie problémov, ktorým čelia predošlá verzia(IPv4) pri použití na internete, pričom jedným z nich je použitie dĺžky adresy 128 bitov namiesto 32.

V súčasnosti sa IPv6 aktívne používa v mnohých sieťach po celom svete, ale zatiaľ sa na internete nerozšíril tak ako IPv4.

Internetový protokol IPv6 zvláda hlavné úlohy dobre. Má výhody internetového protokolu IP a nemá niektoré nevýhody, navyše nemá niektoré nové funkcie. Vo všeobecnosti IPv6 nie je kompatibilný s IPv4, ale je kompatibilný so všetkými ostatnými protokolmi na internete, vrátane TCP, UDP, ICMP, OSPF, DNS, čo niekedy vyžaduje menšie úpravy.

Vlastnosti IPv6:

• Protokol IPv6 má dĺžku 16 bajtov, čo rieši hlavný problém – poskytnúť takmer neobmedzený prísun internetových adries.
• IPv6 má jednoduchšiu hlavičku paketu ako IPv4. Smerovače teda môžu spracovávať pakety rýchlejšie, čo zlepšuje výkon.
• Vylepšená podpora pre voliteľné parametre. Táto zmena bola skutočne významná, pretože predtým povinné polia sa v novej hlavičke stali voliteľnými.
• Vylepšená bezpečnosť, autentifikácia a súkromie sú kľúčovými vlastnosťami nového protokolu IP
• Väčšia pozornosť sa venuje typu poskytovaných služieb. Na tento účel bolo v hlavičke paketu IPv4 pridelené 8-bitové pole.

Štruktúra IP paketov verzie 6 je znázornená na obrázku

• Verzia – pre IPv6 sa hodnota poľa musí rovnať 6.
• Priorita – používa sa na rozlíšenie medzi paketmi s rôznymi požiadavkami na doručenie v reálnom čase.
• Označenie toku - používa sa na vytvorenie pseudospojenia medzi odosielateľom a príjemcom s určitými vlastnosťami a požiadavkami. Napríklad tok paketov medzi dvoma procesmi na rôznych hostiteľoch môže mať prísne požiadavky na latenciu, čo si vyžaduje rezerváciu šírky pásma.
• Dĺžka užitočného zaťaženia – hovorí, koľko bajtov nasleduje po 40-bajtovej hlavičke.
• Ďalšia hlavička – hovorí, ktorá z dodatočných hlavičiek nasleduje po hlavnej.
• Maximálny počet tranzitných uzlov je analogický dobe životnosti (TTL).
• Ďalšie tituly:
• Parametre smerovania - rôzne informácie pre smerovače;
• Možnosti prijímania - Ďalšie informácie pre príjemcu
• Smerovanie - čiastočný zoznam tranzitných smerovačov na ceste paketu;
• Fragmentácia - správa fragmentov datagramov;
• Autentifikácia - overenie odosielateľa;
• Šifrované dáta – informácie o zašifrovanom obsahu.

Typy adries

Unicast- Identifikátor jedného rozhrania. Paket odoslaný na unicast adresu je doručený na rozhranie špecifikované v adrese.

Anycast- Identifikátor množiny rozhraní (patriacich rôznym uzlom). Paket odoslaný na adresu anycast je doručený na jedno z rozhraní uvedených v adrese (najbližšie, podľa miery určenej smerovacím protokolom).

Multicast- Identifikátor množiny rozhraní (zvyčajne patriacich rôznym uzlom). Paket odoslaný na multicast adresu je doručený na všetky rozhrania špecifikované touto adresou.

Broadcastové adresy v IPv6 neexistujú, ich funkcie sú prenesené na multicastové adresy.

V IPv6 sú všetky nuly a všetky jednotky platnými kódmi pre akékoľvek pole, pokiaľ nie je špecifikovaná výnimka.

Model adresovania

IPv6 adresy všetkých typov sú spojené s rozhraniami, nie s uzlami. Keďže každé rozhranie patrí iba jednému uzlu, adresa rozhrania unicast môže identifikovať uzol.

Adresa IPv6 unicast sa mapuje iba na jedno rozhranie. Jedno rozhranie môže mať veľa adries IPv6. rôzne druhy(unicast, anycast a multicast). Z tohto pravidla existujú dve výnimky:

• Jedna adresa môže byť priradená viacerým fyzickým rozhraniam, ak aplikácia pri ich prezentovaní na internetovej vrstve zaobchádza s viacerými rozhraniami ako s jednou entitou.
• Smerovače môžu mať nečíslované rozhrania (napríklad k rozhraniu nie je priradená žiadna adresa IPv6) pre spojenia bod-bod, aby sa eliminovala potreba ručne konfigurovať a inzerovať tieto adresy. Adresy nie sú potrebné pre pripojenia smerovačov typu point-to-point, pokiaľ sa tieto rozhrania nepoužívajú ako východiskový alebo cieľový bod pri odosielaní datagramov IPv6. Smerovanie sa tu vykonáva podľa schémy blízkej tej, ktorú používa protokol CIDR v IPv4.

IPv6 nasleduje model IPv4, kde je podsieť spojená s odkazom. Jeden kanál môže zodpovedať niekoľkým podsieťam.

formy reprezentácie IPv6

Tvar hexadecimálnych čísel a dvojbodiek

Táto forma je výhodná a má formu n:n:n:n:n:n:n:n. Každé znamienko n zodpovedá 4-miestnemu hexadecimálnemu číslu (celkovo 8 hexadecimálnych čísel, pre každé číslo je pridelených 16 bitov).

Napríklad: 1FA9:FFFF:2621:ACDA:2245:BF98:3412:4167.

stlačená forma

Kvôli veľkej dĺžke adresa zvyčajne obsahuje veľa núl za sebou. Pre zjednodušenie zápisu adries sa používa komprimovaná forma, v ktorej sú susedné sekvencie nulových blokov nahradené dvojicami dvojbodiek (::).Takýto znak sa však v adrese môže vyskytovať iba raz.

Napríklad:

• adresa multicast FFEA:0:0:0:0:CA28:1210:4362 má komprimovaný tvar FFEA::CA28:1210:4362.
• Adresa unicast 3FFE:FFFF:0:0:8:800:02A1:0 v komprimovanej forme je: 3FFE:FFFF::8:800:02A1:0.
• Adresa slučky 0:0:0:0:0:0:0:1 v komprimovanej podobe vyzerá takto::1.
• Nedefinovaná adresa 0:0:0:0:0:0:0:0 sa zmení na:: .

zmiešaná forma

Tento formulár je kombináciou adries protokolu IPv4 a IPv6. V tomto prípade má adresa formát n:n:n:n:n:n:d.d.d.d, kde každý znak n zodpovedá 4-miestnemu hexadecimálnemu číslu (6 hexadecimálnych čísel, každému číslu je pridelených 16 bitov) a d.d.d.d je časť adresy zapísaná vo formáte IPv4 (32 bitov).

4. 12. 2018 | Andrej Leuškin

1. februára 2011 boli APNIC odovzdané posledné dva bloky /8 (maximálny počet hostiteľov 16777216). Táto udalosť oznámila svetu, že adresný priestor IPv4 sa skončil. Inými slovami, internetoví registrátori môžu používať iba adresy, ktoré boli predtým získané. Nedostatok IPv4 adries by sa mal riešiť prechodom na IPv6 adresy. Postup migrácie, ako aj skúsenosti s používaním tohto protokolu rôznymi organizáciami, budú diskutované nižšie.

Zahraničné skúsenosti

Veľkí poskytovatelia internetu a služby, ako aj výrobcovia zariadení na počesť osláv Svetového dňa IPv6 zaradili protokol do svojich zariadení. Boli medzi nimi takí giganti ako AT&T, Google, Cisco, Facebook, Microsoft Bing, Yahoo! V čase písania tohto článku tieto a mnohé ďalšie služby naďalej fungujú v segmentoch IPv4 aj IPv6. Napríklad Google Public DNS je dostupný nielen na adresách 8.8.8.8 a 8.8.4.4, ale aj na 2001:4860:4860::8888 a 2001:4860:4860::8844.

Poskytovatelia AT&T a Orange poskytujú svojim zákazníkom dve adresy naraz - jednu IPv4, druhú IPv6, pričom oba parametre súčasne konfigurujú sieťové pripojenie. Ak to v prvom prípade spoločnosti robia pre dostupnosť svojich zdrojov, potom v druhom - pre priamy prístup k nim.
Celkom zaujímavý je fakt, že zahraničné organizácie využívajú IPv6 v dátových centrách a dátových centrách. Vďaka výhodám protokolu (veľké adresné priestory a ľahká hlavička paketov), ​​ako aj vysokej prevalencii virtuálne stroje v porovnaní s fyzickým používaním IPv6 je nutnosťou.

IPv6 sa aktívne implementuje v ázijských krajinách. Problém nedostatku IPv4 adries v Číne je dosť akútny. Podľa tlačovej agentúry Xinhua sa do roku 2020 plánuje zvýšiť aktívnych používateľov až 500 tisíc a do konca roku 2025 sa Čína stane svetovým lídrom v počte používateľov IPv6.

Ruské skúsenosti

Oficiálnych informácií o používaní IPv6 poskytovateľmi je málo, ale niektoré údaje sú dostupné na odkaze. Medzi hlavných poskytovateľov je potrebné vyzdvihnúť Vimpelcom (Beeline) a TTK. Je pozoruhodné, že VimpelCom už vo vnútri úspešne preniesol niekoľko regiónov na IPv6 mobilná sieť a aktívne používa tento protokol.

Bokom nezostali ani veľké ruské internetové spoločnosti. Yandex aktívne používa IPv6 vo svojich sieťach. Poštové služby, DNS a samotný web už majú podporu pre nový protokol. Yandex vo svojom blogu uvádza, že podpora IPv6 vo svete je v priemere lepšia ako v RuNet, a to bol dôvod na organizovanie interakcie poštových služieb medzi servermi. Príklad takejto implementácie je znázornený na obrázku 1.

Samostatným problémom pre Yandex bola takzvaná ochrana proti spamu - súbor programov a databáz na ochranu pred spamom a nechcenými e-mailami. Antispamové algoritmy Yandex.Mail kombinujú nielen štatistické a heuristické metódy, strojové učenie, ale aj rozhodovací mechanizmus založený na týchto faktoroch. Problém bol v tom, že jedna z metód kontroluje IP adresy zapojených počítačov a ukladá reputáciu ich IPv6 adries, ktorých celkový počet výrazne presahuje aj celkové množstvo RAM všetkých serverov Yandex. Inžinieri však našli kompromisné riešenie a problém odstránili.

Čo sa týka vyhľadávače, potom väčšina z nich už funguje nielen na protokole IPv4, ale aj na IPv6, s výnimkou Rambler.ru.

IPv6 v IoT

Zaujímavým faktom je využitie IoT v domácich sieťach. V skutočnosti, internet vecí - ide o akési ideálne prostredie, v ktorom sú všetky „inteligentné“ zariadenia pripojené do jednej siete s priamym prístupom z globálnej siete.

Aký je dôvod použitia? Samozrejme, obrovský adresný priestor. Pozrime sa na obrázok 2. Tu vidíme domáce LAN zariadenie.

• Zariadenia 1 , 2 A 3 schematicky znázornené ako používateľské zariadenia.
• Zariadenie 3 - napríklad server systému "smart home".
• Zariadenie 4 - prístupový bod.
• Zariadenie 6 – smerovač, ktorý poskytuje prístup na internet pre zariadenia domácej siete.
• Komunikačná linka 5 spája prístupový bod s interným rozhraním smerovača.
• Komunikačná linka 7 pripája externé rozhranie smerovača k sieti poskytovateľa ( 8 ). Obe linky používajú protokol IPv6. Riadok 7 (externé rozhranie smerovača) však používa priestor adries /128 a domáca podsieť má predponu /64.

Ďalej je všetka prevádzka prichádzajúca na externý port smerovača „smerovaná“ do internej siete s bielymi adresami IPv6. Prečo nie NAT a nie presmerovanie portov? Podsieť /64 je pomerne veľká a predpokladá existenciu 18446744073709551616 adries. Pravdepodobný počet rôznych druhov senzorov a zariadení jednoducho nemožno priradiť ku konkrétnemu portu tcp na externé rozhranie. Malo by byť zrejmé, že vnútorná sieť nie je obmedzená na štyri zariadenia a nie všetky zariadenia inteligentného domáceho systému budú pripojené k serveru, ale budú priamo prístupné.

Priemyselné aplikácie IPv6

Aplikácia a prechod z IPv4 na IPv6 v priemysle je rovnako opodstatnený ako aplikácia v systéme inteligentnej domácnosti. Existuje akútny problém s nedostatkom IPv4 adries. Konkrétnym príkladom je ropný a plynárenský priemysel a v ňom používané snímače M2M. Všeobecná schéma interakcie je znázornená na obrázku 3.

Stručne povedané, informácie zo staníc na ťažbu ropy alebo plynu sa prenášajú do jedného dispečerského centra (pre informáciu: v Rusku je asi 140 ropných polí a 11 najväčších plynových polí). Na jednom poli môže byť niekoľko takýchto staníc. Zdalo by sa, že nie až také veľké množstvo, ale ropa alebo plyn vystúpený na povrch sa prepravuje cez hlavné ropovody alebo plynovody a celý proces potrebuje neustále monitorovanie, a to sú státisíce rôznych senzorov, prístrojov a čerpacích staníc .

Interakcia M2M (machine-to-machine / machine-to-machine) je implementovaná vďaka mobilným operátorom. M2M je možné nasadiť takmer v každom odvetví – bývanie a komunálne služby, mestská doprava a platobné terminály (ATM).

Bežné problémy:

1. Hardvér musí podporovať IPv4v6 Dual-Stack.
2. Použitie IPv4v6 Dual-Stack v sieťach poskytovateľov (nielen) znamená úplné zmeny v chrbticových a dopravných sieťach, platformách služieb, fakturácii, SORM a pod.
3. Klientske zariadenie v inej sieti musí pochopiť, čo je IPv6. Ak ISP klienta „nerozumie“ IPv6, zostáva jedinou možnosťou tunelovať IPv6 vo vnútri tunela IPv4.
4. Populácia siete IPv6 je slabá a väčšina zdrojových služieb beží na IPv4.

• 2a02:6b8::feed:0ff - napájanie vypnuté, adresa základného servera
• 2a02:6b8::feed:bad - zlý zdroj, zabezpečená adresa servera
• 2a02:6b8::feed:a11 - feed all, adresa rodinného servera (adresy s obsahom 18+ sa nevydávajú)

Myslím, že preklad nepotrebuje.

Cieľom spoločnosti Google je, aby si ľudia zapamätali s najväčšou pravdepodobnosťou svalovú a vizuálnu pamäť:

• 2001:4860:4860::8888
• 2001:4860:4860::8844

Prvým segmentom je číslo 2001. Zaujímavým spojením medzi Googlom a rokom 2001 je, že podľa príslušných Vyhľadávací dopyt môžete prejsť na stránku, kde sa nachádza fráza „Google: Let's Query Like It's 2001“, čo v preklade znamená „Google, skúsme to ako v roku 2001“. V tom roku spoločnosť spustila PR (PageRank), jeden z algoritmov hodnotenia odkazov.

Druhý a tretí segment sú čísla 4860, dajú sa veľmi pohodlne písať na numerickej časti klávesnice.

Nasleduje segment obsahujúci 0000, ale skratka záznamu robí zadávanie núl voliteľným.
Posledný segment 8888 v primárnej adrese a 8844 v alternatívnej adrese sú v podstate odkazom na adresy v IPv4 - 8.8.8.8 a 8.8.4.4.

Záver

Ako ukázala prax, IPv6, aj keď pomaly, sa v modernom svete používa. Napriek problémom spojeným s prechodom na Nová verzia Internetový protokol je dôležitým a významným krokom pre každého bez výnimky. VAS Experts je teraz pripravený ponúknuť svojim zákazníkom, aby začali používať IPv6, ktorého implementácia bola pridaná najnovšie verzie SKAT DPI. V budúcnosti plánujeme vyvinúť Dual Stack (tvarovanie, služby, ukončenie, výdajné adresy), ako aj plnú podporu technológie NAT.
Viac detailné informácie o výhodách moderný systém Pre hĺbkovú analýzu prevádzky SCAT DPI, jej efektívne využitie v sieťach telekomunikačných operátorov, ako aj migráciu z iných platforiem sa môžete dozvedieť od špecialistov spoločnosti VAS Experts, vývojára a dodávateľa systému analýzy návštevnosti SCAT DPI.
Prihláste sa na odber bulletinu blogu, aby vám neušiel nový obsah.

ProtokolIPv6 je rozšírenie IPv4. Napríklad aplikácie, ktoré používajú transportnú a aplikačnú vrstvu, potrebujú len malé alebo žiadne zmeny, aby mohli začať IPv6.

Protokol IPv6 vykonáva množstvo pokročilých funkcií.

Veľký adresný priestor. Hlavným dôvodom zmien verzie použitého protokolu IP je väčší adresný priestor: adresy v IPv6 sú dlhé 128 bitov (oproti 32 bitom in IPv4). Väčší adresný priestor zabraňuje potenciálnemu problému s vyčerpaním priestoru adries protokolu IPv4.

Automatická konfigurácia uzla. Uzol IPv6 možno konfigurovať automaticky pri pripojení k sieti s IPv6-smerovanie pomocou protokolu správ ICMPv6. Pri prvom pripojení uzol odošle požiadavku na svoje konfiguračné parametre (vyžiadanie smerovača) a ak je to možné, smerovač odošle paket s nastaveniami sieťovej vrstvy pre tento uzol (reklama smerovača). Ak IPv6 nie je z akéhokoľvek dôvodu použiteľný, hostiteľ môže byť nakonfigurovaný manuálne.

supergramy (Jumbogramy). IN IPv4 pakety sú obmedzené na 64 kilobajtov užitočného zaťaženia. IN IPv6 bolo možné obísť toto obmedzenie používaním takzvaných supergramov, ktoré umožňujú použitie balíkov s veľkosťou až 4 megabajty. Použitie takéhoto paketu v lokálnej sieti alebo v bežnom internetovom kanáli sa zdá byť nevhodné a na diaľniciach a iných sieťových kanáloch s vysokou kapacitou je výhodou prenos menšieho počtu paketov väčšieho objemu.

Zabezpečenie siete. Protokol na ochranu IP siete IPSec (Internet Protocol Security), ktorý implementuje vrstvu šifrovania a autentifikácie, je neoddeliteľnou súčasťou základného protokolu v IPv6, Na rozdiel od IPv4 kde sa to považovalo za voliteľné.

Kvalita služby(Kvalita služby, QoS). Táto inovácia je založená na myšlienke diferenciácie služieb, čo je potreba poskytnúť možnosť vybrať si a zaplatiť za úroveň služieb, ktorá sa líši od predvolenej. Možnosti zahŕňajú garantované doručenie, expresné doručenie, dočasné pridelenie významnej šírky pásma, minimálne náklady na doručenie (možno na úkor rýchlosti doručenia) a mnoho ďalších možností, ktoré môžu byť uprednostnené pre konkrétnych používateľov v závislosti od konkrétneho času a miesta, kde sa nachádzajú. V protokole IPv4 je systém QoS čiastočne implementovaný, ale nedostal sa do širokej distribúcie.

mobilných používateľov. Mobilita bola čiastočne riešená v IPv4, ale nebola široko prijatá ako notebooky, PDA a Mobilné telefóny začali byť široko používané nie tak dávno; s rozvojom bezdrôtových technológií sa to však nedalo nezdokonaliť v novom protokole IPv6, v štandardoch ktorého sa rozlišujú dva typy mobility: normálna mobilita a mikromobilita. zvyčajne mikromobilita komunikuje s linkovou vrstvou (bezdrôtové pripojenie). Tu je vhodné nakresliť analógiu s celulárnou komunikáciou: v oboch prípadoch sa zvažujú spôsoby implementácie možnosti presúvania mobilného zariadenia medzi bezdrôtovými prístupovými bodmi bez prerušenia spojenia. Projekt je vyvíjaný v spolupráci so spoločnosťami vyvíjajúcimi bezdrôtové sieťové technológie Wi-Fi a Wi-MAX, o ktorých sa predpokladá, že v budúcnosti úplne vytlačia celulárnu komunikáciu z trhu a stanú sa základom pre IP telefóniu, ktorá v poslednom čase naberá na sile. Iný druh mobility nachádza uplatnenie v trochu väčšom meradle, keď sa napríklad používateľ potrebuje prihlásiť do siete v Moskve a vymieňať si informácie s klientom v New Yorku, ako keby bol v vlastnú sieť do Tokia, v takom prípade nemusí posielať všetky správy cez pol sveta. Riešenia a štandardy na podporu mobilných používateľov sú stále vo vývoji.

Predpokladá sa, že všetky tieto inovácie budú kľúčom k dlhodobému používaniu protokolu IPv6 ako hlavného protokolu pre prácu v sieti, predovšetkým na internete.

pakety protokolu IPv6 pozostávať od hlavička trvalého formátu , prídavné rozširujúce hlavičky , aužitočné zaťaženie (dáta) . Všetky tieto prvky sú zapuzdrené v rámci spojovacej vrstvy.

IPv6 -hlavička navrhnuté tak, aby skrátili čas spracovania v cieľovom a medziľahlých smerovačoch. Hlavička IPv6 nemá premennú dĺžku – vždy má 40 bajtov. Formát hlavičky IPv6 sa líši od štruktúry hlavičky paketu IPv4 znížením počtu polí (niektoré boli odstránené ako nepotrebné, pridané nové, niektoré upravené a názvy zmenené). Štruktúra paketu IPv6 je znázornená v ryža. 2.8.

Obrázok 2.8 - ŠtruktúraIPv6-balenie

V teréne Verzia (verzia) uveďte, že táto hlavička odkazuje na protokol IPv6; hodnota tohto 4-bitového poľa je 6.

Nové pole Trieda (trieda) poskytuje podporu pre prioritizáciu prevádzky. Prvý úder poliachD označuje, že prevádzka je citlivá na latenciu. Ak sa rovná jednej, potom prevádzka závisí od časových charakteristík. Napríklad interaktívna výmena dát, ako aj audio a video komunikácia vyžadujú pripojenia s nízkou latenciou. Preto v paketoch obsahujúcich užitočné zaťaženie týchto typov je prvý bit poľa trieda zvyčajne sa rovná jednej. Lúka Prednosť (prednosť) podobné zodpovedajúcemu poľu v hlavičke IPv4 a umožňuje aplikácii rozlišovať typy prevádzky na základe ich priorít. V súlade s tým môžu smerovače odkazovať na prioritné bity, aby uprednostnili prevádzku počas spracovania a zaraďovania do frontu. Posledné štyri časti poľa trieda V tento moment sú rezervované.

Lúka prúdiť (tok) spravuje skupinu paketov, ktoré musia byť na žiadosť zdroja spracované špeciálnym spôsobom medziľahlými smerovačmi. Pole sa zvyčajne nepoužíva: štandardne je vyplnené 20 nulami.

Lúka Dĺžka užitočného zaťaženia (užitočné zaťaženie Dĺžka) obsahuje informáciu o množstve dát za IPv6 hlavičkou (samotná hlavička sa nepočíta). Pole Payload Length je dlhé 2 bajty.

V teréne nasledujúci nadpis (Ďalšie hlavička) , ktorý je dlhý 1 bajt, označuje následnú hlavičku rozšírenia, transport alebo nejaký iný protokol (Tabuľka 2.3). Mnohé z hodnôt uvedených v tabuľke sú typické aj pre paket IPv4 (hodnoty v zátvorkách sú len pre pakety IPv6).

Tabuľka 2.3 - Hodnoty poľaĎalšie hlavička

Význam	Typ hlavičky
	Možnosti medzi skokmi (IPv6)
	Internet Message Control Protocol ICMP
	Internetový protokol IGMP Group Management
	Zapuzdrenie paketu IPv4 do paketu IPv6 (IPv6).
	Tok (IPv6)
	TCP Transmission Control Protocol
	UDP protokol užívateľského datagramu
	Smerovacia hlavička (IPv6)
	Hlavička fragmentácie (IPv6)
	Hlavička overenia (IPv6)
	Internet Message Control Protocol ICMP (IPv6)
	Žiadna ďalšia hlavička (IPv6)
	Hlavička možností cieľa (IPv6)

Lúka Limit verejnej dopravy (Hop limit) v protokole IPv4 je tzv Život. Tento názov zodpovedá skutočnému poradiu jeho použitia v oboch verziách protokolu.

Lúka Adresa zdroja (Zdroj Adresa) identifikuje 16-bajtovú IP adresu odosielajúceho hostiteľa.

Lúka cieľová adresa (Destinácia Adresa) identifikuje 16-bajtovú IP adresu prijímajúceho hostiteľa.

V IPv6 musí byť hlavička rozšírenia umiestnená medzi hlavičku IP a hlavičky protokolu vyššej vrstvy. V súčasnosti poskytuje špecifikácia protokolu IPv6 podporu pre šesť hlavičiek rozšírenia, ktorých poradie je uvedené v ryža. 2.9.

Ryža. 2.9 - Umiestnenie hlavičiek v paketeIPv6

Hlavička rozšírenia možností medzitranzit určený na prenos dát do smerovačov umiestnených po celej dĺžke celej cesty. Ak sa napríklad vyžaduje multicasting na doručenie akýchkoľvek smerovacích pokynov do siete, tieto pokyny možno umiestniť do tejto hlavičky a medziľahlé smerovače pozdĺž trasy túto hlavičku analyzujú. Existujú dva návrhy na použitie tohto nadpisu:

1) prenos upozornení do smerovačov;

2) prenos možností služby QoS.

Hlavička rozšírenia možností cieľa predstavuje spôsob rozšírenia hlavičky IPv6 o podporu možností spracovania a nastavení paketov. Tento nadpis umožňuje budúce použitie značkových a štandardizovaných správ. Hodnoty typu možnosti bude potrebné zaregistrovať v organizácii IANA (internet pridelených čísla autorita (www.iana.org)) a ​​popísané v špeciálnom Internetové štandardyRFC (Žiadosť Pre Komentáre).

Hlavička rozšírení smerovania Protokol IPv6 poskytuje podporu pre prísne smerovanie od zdroja k cieľu. Táto hlavička obsahuje polia na špecifikovanie medziľahlých adries, cez ktoré sa majú prenášať pakety IPv6. Odosielateľ teda vypočíta cestu cez všetky smerovače, ktoré majú daný paket spracovať. Uvádza ich adresy v zoradenom zozname, pričom adresu smerovača konečného cieľa umiestni na úplný koniec zoznamu. V poli je uvedená adresa prvého smerovača v ceste Cieľová adresa hlavička IPv6. V normálnych prípadoch stredné smerovače preposielajú paket bez toho, aby sa pozreli na obsah hlavičiek. Keď paket dorazí k prvému smerovaču, hľadá presne túto hlavičku. Ak je všetko v poriadku, smerovač umiestni adresu ďalšieho smerovača do zoznamu v poli Cieľová adresa a presunie svoju adresu na koniec zoznamu. Tento proces sa opakuje, kým paket nepríde na svoje konečné miesto určenia. V takomto zozname možno zadať až 255 adries smerovačov.

IPv6 zakazuje fragmentáciu paketov počas prenosu (na smerovačoch). Pôvodný odosielateľ je povinný pred odoslaním paketu skontrolovať MTU do cieľa a fragmentovať dáta podľa tejto prenosovej jednotky. Ak vysielacie zariadenie potrebuje odoslať pakety, ktoré presahujú hodnotu MTU, hlavička fragmentačných rozšírení protokol IPv6.

Hlavička rozšírení na overenie totožnosti je určený na zistenie skutočného pôvodu balíka v prípadoch hackerských útokov (krádeže paketov) pomocou falošných IP adries. Táto hlavička tiež poskytuje kontroly integrity pre tie časti paketu, ktoré zostávajú počas prenosu nezmenené.

Zapuzdrená hlavička bezpečnostných rozšírení slúži na šifrovanie údajov a mal by byť vždy posledný v reťazci hlavičiek IP.

Preto je protokol IPv6 svojou vnútornou štruktúrou a funkčnosťou jednoznačne nadradený protokolu IPv4 a je jeho dôstojnou náhradou. Zatiaľ sa za hlavný protokol považuje IPv4 a IPv6 má len čiastočné využitie. Až kým IPv6 nakoniec nenahradí IPv4(čo sa v dohľadnej budúcnosti pravdepodobne nestane), budú potrebné prechodné opatrenia IPv6-uzly by sa mohli uplatniť IPv4-služby a do izolovaných IPv6-použití hostitelia a siete IPv6- Internet cez IPv4-infraštruktúra.

Existujú 2 možnosti riešenia tohto problému.

Dvojvrstvový prístup. Pretože IPv6 je rozšírenie IPv4, je možné vytvoriť sieťový zásobník, ktorý podporuje oboje IPv4, a IPv6. Takáto implementácia sa nazýva duálny zásobník a implementácia duálneho zásobníka pre uzol sa nazýva uzol s dvojitým zásobníkom.

PretunelovanieIPv4. Aby ste sa dostali do IPv6-Internet, izolovaní hostitelia alebo siete musia byť schopné využívať existujúce infraštruktúry IPv4 na prenos IPv6-balíčky. Dá sa to urobiť pomocou techniky známej ako tunelovanie, ktoré pozostáva zo zapustenia IPv6-balíčky v IPv4(v skutočnosti, IPv4 sa stáva ako kanálová vrstva pre IPv6).

Úplný prechod na IPv6 a vyššie uvedené riešenia znamenajú úplné opustenie súčasného spínacieho zariadenia, ktoré funguje iba s protokolom IPv4. Prechod na nové zariadenia v lokálnych sieťach a internete si vyžiada materiálne náklady, čo, samozrejme, bráni aj implementácii protokolu IPv6. Hlavné fázy úvodu IPv6 sú nasledovné:

1) výmena alebo blikanie zastaraného zariadenia;

2) poskytnúť výrobcom nových zariadení dostatočné informačné zdroje na spracovanie IPv6;

3) investície do vývoja nového softvéru na podporu IPv6;

4) poskytovanie publicity (presvedčiť koncových užívateľov o užitočnosti prípravy na modernizáciu existujúcich zariadení);

5) oznamovanie informácií koncovým používateľom (na vytvorenie dopytu po IPv6- vybavenie);

6) investície poskytovateľov technických zdrojov do prípravy IPv6.

Ako príklad podpory IPv6 vytvorili organizátori Letných olympijských hier 2008 v Pekingu kópiu hlavnej stránky na adrese IPv6 http://ipv6.beijing2008.cn/en(IP adresa: 2001:252:0:1::2008:6 a 2001:252:0:1::2008:8). Všetky sieťové interakcie na olympijských hrách sa plánovali vykonávať pomocou IPv6. Toto podujatie možno považovať za najväčšiu technologickú demonštráciu IPv6 od svojho vzniku.

Naposledy bolo Rusku opäť vyčítané, že nedodržalo
jeden medzinárodný záväzok. generál
Tajomník Rady Európy Terry Davis, komentuje
Neschopnosť Ruska splniť si svoju povinnosť zrušiť
trest smrti, povedal: „Som prekvapený týmto pokusom
Ruskí predstavitelia prezentujú prípad tak, že
Moskva tento sľub už splnila. IN
Rozhodnutie o zrušení trestu smrti v skutočnosti nie je
ratifikovaný ruskými zákonodarcami, čo znamená
- Zrušenie nebolo vykonané. Ukázalo sa, že Rusko je
jediný zo 46 krajín
— členovia Rady Európy, ktorí toto neimplementovali
povinnosť."

Pred deviatimi rokmi bolo Rusko prijaté do Rady
Európe a 28. februára 1996 podpísal Protokol č.6
zo dňa 29. apríla 1983 k Európskemu dohovoru o
ochrany ľudských práv a základných slobôd. Toto
protokol zakazuje používanie v čase mieru
trest smrti ako trestný trest. IN
v súvislosti s podpísaním protokolu N6 prezidentom Ruskom
Rusko podpísal Boris Jeľcin v máji 1996.
osobitná vyhláška „o postupnom znižovaní používania
trest smrti v súvislosti so vstupom Ruska do Rady
Európa“. Na príkaz Jeľcina od augusta 1996
Prestali sa dávať „strieľacie“ vety
exekúcie.

Ústavný súd Ruskej federácie 2. februára
1999 vydal rozsudok, podľa ktorého
trest smrti nemožno uložiť skôr
fungovanie poroty v celej krajine.
Posledný ruský región, v ktorom od roku 2007
začnú fungovať porotné procesy - to je Čečenec
republika. Preto je možné, že v roku 2007
Rusko znovu zavedie trest smrti
ako trestný trest. Na finále
zrušenie trestu smrti v Rusku
je potrebná ratifikácia federálnym parlamentom
uvedeného Protokolu č.6.

Naposledy Štátna duma oficiálne
riešil otázku zrušenia moratória na smrť
exekúcie dňa 22. 9. 2004. Dňa poslanci
zamietol pozmeňujúce a doplňujúce návrhy k uzneseniu Dumy,
ktorým sa ustanovuje odmietnutie ratifikovať protokol č
6. Potrebným počtom 226 hlasov boli pozmeňujúce a doplňujúce návrhy podporené
len 95 poslancov.

K dnešnému dňu situácia s Protokolom č
vyvinulo sa dosť zvláštne: na jednej strane
zákonodarcovia oficiálne odmietajú
ratifikovať tento protokol a na druhej strane ešte nie
ide ratifikovať. Poslanci čakajú. ich
možno pochopiť: oni a pred civilizovanou Európou
zahanbený a nepríjemný pred vlastným ľudom.

Ako sa vyjadrila väčšina poslancov
Pavel Krasheninnikov, choďte dnes zrušiť
trest smrti zasahuje do parlamentnej „verejnosti
názor“. A " verejný názor", ako
uhádol čitateľ, to je názor práve tých
Rusi, ktorí idú voliť v decembri 2003
zvolil súčasných poslancov štátu
Duma. To je názor práve tých Rusov, ktorí dnes
žiť v krajine, ktorá sa stáva svetovým lídrom
počet vrážd. Len minulý rok v Rusku,
Podľa oficiálnych štatistík boli
31553 vrážd a pokusov o vraždu, 57352
úmyselné ublíženie na zdraví,
pri ktorej zomrelo veľa ľudí.

Dnes na svete v 78 štátoch a ich
územné celky si ponechali úmrtie
exekúcie. Medzi nimi sú USA, Japonsko, Čína, Irán, Vietnam
a iné štáty. Dovoľte mi uviesť niekoľko čísel
krajina ako USA. V legislatíve 38 z 50
Štáty USA ustanovujú trest smrti.
Okrem toho v tejto krajine trest smrti
ustanovené pre určité druhy trestných činov a v
federálny zákon. Aktuálne v
Na popravu smrteľníka čaká v USA asi 4000 ľudí
veta.

Podľa Amnesty International,
minimálne v roku 2003
najmenej 1146 ľudí v 28 krajinách, v ďalších 63 krajinách
Na smrť bolo odsúdených 2756 ľudí.

V roku 1992 to Najvyšší soviet Ruska povolil
o milosť nahradiť trest smrti doživotným väzením
záveru a od roku 1996 u nás tento druh
trest namiesto trestu smrti. Ak v
1997 na doživotie si odpykávalo 177 osôb
ľudí, potom začiatkom roku 2003 už 1115 ľudí.
Prevažná väčšina odsúdených sa dopustila dvoch a
viac zabití. V priemere na jedného väzňa
doživotné väzenie predstavuje štyri obete.
Priemerný vek týchto zločincov je 33 rokov. Mimochodom,
v Rusku udržiavanie jedného doživotne odsúdeného väzňa
stojí okolo 3000 eur ročne.

... V jednom zo svojich nedávnych rozhovorov Alexander
Solženicyn citoval málo známu historickú epizódu:
„Otec spisovateľa Nabokova, Vladimír Dmitrievič
Nabokov, významný ruský štátnik,
verejný činiteľ, sa rozhodol zrušiť
v Rusku trest smrti (čiastočne pod vplyvom
Tolstoj). Venoval tomu dvadsať rokov svojho života
hlavný cieľ - od konca 19. storočia do septembra 1917
d) Prečo sa to všetko skončilo 17. septembra? TO
17. septembra sa všetka lajdácka ohavnosť rozpadla
februára sa začalo zabíjanie bezdôvodne, bez
bezpečnostná beztrestnosť. Prišiel Nabokov
Mestská duma v Petrohrade a tretieho septembra
predniesol prejav: „Dvadsať rokov som bojoval naplno
zrušenie trestu smrti. Mýlil som sa. Nemôžeme
riešiť inak ako trest smrti. Existujú
také prípady, keď pre záchranu celej spoločnosti za
na záchranu štátu je potrebný trest smrti...“

Zástupcovia oboch vzájomne sa vylučujúcich pozícií
zachovanie trestu smrti a jeho zrušenie
závažné argumenty, ktoré si zaslúžia pozornosť a
štúdium. Ale riešenie tohto najťažšieho problému
jeden musí byť prijatý.

Podľa mňa najsprávnejšia cesta von
súčasná situácia je konať
celoštátne referendum o otázke smrti
exekúcie. Veď podľa Ústavy najdôležitejšie
zákonodarcom u nás je ľud. Nie nadarmo
Hovoria, že hlas ľudu je hlas Boží.