Slidy z prednášky
YouTube

1.  NAT: Network address translation

Úlohou NAT routra je sprostredkovať komunikáciu staníc v privátnej neverejnej sieti s verejnou sieťou. NAT je bežnou doplnkovou službou aj lacných routrov pre domácnosti. Typická situácia je, že provider pridelí pre domácnosť alebo malú firmu jedinú IPv4 adresu, ale tí chcú pripojiť na internet viac staníc ako jednu. Keďže každé zariadenie by malo mať pridelenú vlastnú IP adresu, tak bez NAT routra by sme si museli žiadať od providera viac IP adries (a obvykle aj za vyššiu cenu).

Takže si predstavme, že nám provider pridelil verejnú IP adresu 138.76.29.7, ale my chceme pripojiť do internetu 3 počítače. Vieme, že každé rozhranie routra musí mať tiež svoju IP adresu. Nastavíme teda pre rozhranie routra označené WAN (wide area network) IP adresu 138.76.29.7. Na LAN (local area network) rozhraní routra nastavíme nejakú neverejnú IP adresu určenú pre privátne siete (pozri predchádzajúcu prednášku, kapitolu „Špeciálne IP adresy“) napríklad 10.0.0.4/8 a počítačom v tejto našej nastavíme postupne IP adresy 10.0.0.1/8, 10.0.0.2/8 a 10.0.0.3/8 (toto nastavenie môžeme vykonať alternatívne aj v DHCP serveri a nechať počítače, nech si tieto IP adresy nastavujú dynamicky).

Keby sme použili obyčajný router bez NAT, tak by nebol problém odoslať pakety z tejto siete, keďže routre sa riadia iba cieľovými IP adresami, ale problém by bol nejaké pakety prijať. Predstavme si, že chceme z počítača s IP adresou 10.0.0.1 získať webovú stránku z webového servera na adrese 128.119.40.186. Pri pokuse o vytvorenie TCP spojenia dostane tento server paket s cieľovou IP adresou 128.119.40.186 a portom 80 (známy port pre HTTP). Zdrojová IP adresa by však bola 10.0.0.1. Keďže takáto adresa sa vo verejnom internete nenachádza, SYNACK segment z tohto servera by si nikdy nenašiel cestu k nášmu počítaču.

NAT router ukrýva za seba celú privátnu sieť tak, že sa z internetu nejaví ako router, ale ako obyčajný počítač. Ľubovoľný paket z ľubovoľného počítača v privátnej sieti, ktorý je preposlaný cez NAT router do internetu, je zmenený tak, aby to vyzeralo, že pôvodný odosielateľ je WAN rozhranie NAT routra. Keďže WAN rozhranie NAT routra má verejnú IP adresu, pakety určené pre túto IP adresu prídu správne k tomuto rozhraniu. Úlohou pre NAT router je teraz zmeniť pre pakety prichádzajúce z internetu cieľovú adresu tak, aby to bola správna IP adresa a správny port počítača v privátnej LAN sieti (teda v našom príklade adresa 10.0.0.1).

Celý proces je pekne viditeľný na nasledujúcom obrázku.

  1. Stanica v privátnej sieti s neverejnou IP adresou 10.0.0.1 vyšle paket s cieľovou adresou 128.119.40.186 a cieľovým portom 80. Táto stanica očakáva odpoveď na porte 3345, nastaví teda zdrojový port 3345 a zdrojovú IP adresu 10.0.0.1. Keďže adresa 128.119.40.186 nie je v lokálnej sieti, paket je poslaný cez default router 10.0.0.4.
  2. NAT router vezme tento paket, otvorí jeden z voľných portov pre WAN rozhranie, na našom obrázku port 5001, a zapíše si do prekladovej tabuľky, že ak príde na WAN rozhranie paket s cieľovou IP adresou 138.76.29.7 a cieľovým portom 5001, má poslať tento paket počítaču 10.0.0.1 na port 3345. Následne zmení paket tak, že zmení zdrojovú IP adresu na adresu WAN rozhrania a zdrojový port na 5001 a odošle paket smerom k cieľu 128.119.40.186.
  3. Keď príde na WAN rozhranie paket s cieľovou IP adresou 138.76.29.7 a cieľovým portom 5001, zmení cieľovú IP adresu na 10.0.0.1 a cieľový port na 3345 a odošle tento paket do privátnej siete.
  4. Z pohľadu počítača 10.0.0.1 to ani nevyzerá tak, že má neverejnú IP adresu – ani nevie, že je za NAT routrom.

Počet počítačov v privátnej sieti síce nie je limitovaný, ale keďže čísla portov môžu byť z rozsahu 0 až 65535, tak maximálne môže byť súčasne aktívnych 65535 spojení. Keďže bežný počítač máva aktívnych súčasne iba pár spojení (alebo pár stovák, ak práve intenzívne používa P2P softvéry), dá sa predpokladať, že okolo 100 počítačov v privátnej sieti by určite nemalo mať problém komfortne komunikovať s internetom.

Výhodou NATu je to, že aj v čase, keď začína byť IPv4 adries nedostatok, stále sa dá pripájať mnoho nových zariadení. Nevýhodou je to, že ak chcete otvoriť na niektorom z počítačov serverovú aplikáciu, žiadni noví klienti sa na vás nevedia priamo napojiť, lebo nemáte verejnú IP adresu. Ide o takzvaný NAT traversal problém. Týmto problémom dosť trpia P2P softvéry, ktoré predpokladajú, že každý peer je súčasne klient, ktorý sťahuje súbory, aj server, ktorý zdieľa a poskytuje stiahnuté súbory.

NAT traversal problém sa dá vyriešiť niekoľkými spôsobmi:

  • Ručné nastavenie NAT prekladovej tabuľky umožňuje špecifikovať, kam majú byť preposielané pakety pre určité porty. Dá sa napríklad nastaviť aj to, že ľubovoľné nové pripojenia majú byť preposielané k danému počítaču. Ručné nastavenie je trochu nepohodlné, ale vcelku efektívne, ak chceme nejaký server prevádzkovať dlhodobo.
  • Mnohé NAT routre poskytujú na svojom LAN rozhraní službu IGD (Internet gateway device), označovanú aj ako UPNP (universal plug and play), ktorá umožňuje stanici v lokálnej sieti zistiť verejnú IP adresu NAT routra na WAN rozhraní, zistiť aktuálny stav prekladovej tabuľky a hlavne pridávať a odoberať riadky v prekladovej tabuľke. Tým pádom, ak chceme aktuálne počúvať na nejakom svojom porte môžeme si nastaviť prekladovú tabuľku na NAT routri a navyše informovať okolie o tom, na akej IP adrese a porte bude NAT router počúvať (a odtiaľ preposielať na našu stanicu a náš port)
  • Tretie riešenie je využiť nejaký počítač s verejnou IP adresou a všetku komunikáciu daného spojenia preposielať cez neho. Toto riešenie využíva napríklad Skype. Ak je volaný účastník za NAT routrom, vyberie sa stanica s verejnou IP adresou, na ktorú sa napojí volaný aj volajúci a celý rozhovor je potom preposielaný cez túto stanicu.

2.  Protokol ICMP

ICMP: internet control message protocol, RFC 792

Protokol ICMP používajú stanice a routre, aby sa navzájom informovali o situácii v sieti. Najčastejšie použitie ICMP je na chybové správy o nedostupnosti siete, stanice, protokolu alebo portu.

ICMP protokol je sieťový protokol, ktorého správy sa prenášajú v tele IPv4 datagramu podobne ako TCP alebo UDP segmenty. Niekedy je preto považovaný za transportný protokol. My ho však za transportný považovať nebudeme, lebo neprenáša žiadne dáta aplikačnej vrstvy.

Hlavička ICMP protokolu obsahuje dve čísla code a type, ktoré dohromady určujú typ správy. Chybové ICMP správy majú navyše v tele aj hlavičku a prvých 8 bajtov tela datagramu, ktorý chybu spôsobil. Všetky typy správ si pozrite v RFC 792 alebo ešte lepšie na stránkach organizácie IANA.

ICMP správy sa používajú aj na diagnostiku siete. Ak chceme zistiť, či je stanica s nejakou IP adresou dostupná, použijeme program ping, ktorý vyšle ICMP správu „echo request“ (type 8 code 0) a ak je stanica dostupná (a nemá nastavený firewall tak, že ICMP správy neprijíma), tak odpovie ICMP správou „echo reply“ (type 0 code 0) a my vieme, že je zapnutá.

Veľmi užitočným pomocníkom na diagnostiku siete je aj program traceroute alebo tracert. Je založený na tom, že keď uplynie životnosť datagramu, router tento paket zahadzuje a posiela ICMP správu TTL expired (type 11 code 0). Traceroute vysiela datagramy najprv s TTL=1, potom s TTL=2 a tak ďalej, až pokiaľ niektoré datagramy „neprežijú“ celú cestu k cieľovej stanici. TTL sa na každom routri znižuje o 1, alebo sa datagram zahadzuje ak dosiahne TTL hodnotu nula. To znamená, že najprv prídu ICMP správy TTL expired z najbližšieho routra, potom z druhého na ceste k cieľu, a tak ďalej.

Podľa toho, aký typ správ bol zasielaný, reaguje cieľová stanica rôzne. Ak bol použitý v posielanom IP datagrame UDP segment, ktorému sa bežne nastavuje nejaký port, ktorý je pravdepodobne neotvorený, vráti sa ICMP správa destination port unreachable (typ 3 code 3). V prípade, že sa použil TCP SYN segment, ktorý sa v ICMP bežne používa s portom 80, tak príde buď ICMP správa destination port unreachable alebo SYNACK segment, keďže sa predpokladá, že chceme nadviazať TCP spojenie na webový server. Tiež sa môže použiť ICMP správa „echo request“, vtedy z cieľa príde ICMP správa „echo reply“. To, aký bude typ odosielaných správ, sa dá nastaviť prepínačmi programu traceroute (tracert).

Ak je niektorý router na ceste vypnutý či nefunkčný, dočkáme sa asi ICMP správy destination network unreachable (type 3 code 0) od routra pred ním. Ak je vypnutá iba cieľová stanica, príde z posledného routra na ceste správa destination host unreachable (type 3 code 1).

3.  Sieťový protokol IP verzie 6 (IPv6)

IPv6: internet protocol, version 6, RFC 2460

Protokol IPv4 sa postupne nahrádza protokolom IPv6. Hlavnou zmenou je dlhšia IP adresa, ktorá už nezaberá 32, ale až 128 bitov. Tým pádom by už nikdy nemal vzniknúť stav, že sa voľné IP adresy začnú rýchlo míňať, ako to začíname pociťovať pri protokole IPv4. Samozrejme, už len kvôli dlhším adresám, musí IPv6 používať inú hlavičku ako IPv4.

Význam jednotlivých častí hlavičky IPv6:

  • version, teda verzia IP protokolu má v sebe číslo 6
  • traffic class, teda prenosová trieda určuje charakter dát prenášaných v tomto IPv6 datagrame a jej význam je podobný ako type of service v IPv4. Určuje dôležitosť prenášaných dát, ktorá sa môže na routroch brať do úvahy na „prednostné vybavenie“.
  • flow label je 20 bitová informácia identifikujúca tok dát. Toto číslo ešte nemá presné určenie použitia a má sa vyšpecifikovať priebežne podľa potreby. Predpokladané použitie je v kombinácii s hodnotou traffic class pre identifikovanie multimediálnych prúdov dát ako TV, rádiá, videokonferencie, alebo ako identifikátor zákazníka, ktorý si priplatil za špeciálnu prioritu svojich datagramov.
  • payload length predstavuje veľkosť tela datagramu v bajtoch bez hlavičky, ktorá má vždy 40 bajtov.
  • next header zodpovedá políčku protocol v IPv4 a určuje, že hlavička akého protokolu sa nachádza v tele datagramu, teda hneď za hlavnou hlavičkou Ipv4 datagramu. Typicky to je TCP alebo UDP hlavička, ale môžu to byť aj iné hlavičky ako ICMP či dokonca hlavička protokolu IPv4 prenášaná cez IPv6. Novinkou oproti IPv4 je, že nasledujúcou hlavičkou môže byť aj rozširujúca hlavička. IPv6 má definovaných celkovo 8 rozširujúcich hlavičiek. Je možné použiť žiadnu, niektoré, aj všetky. Tieto hlavičky sú za sebou zreťazené cez „next header“. Ich zameranie je rôzne – na fragmentáciu, šifrovanie cez IPsec, mobilitu a iné.
  • hop limit zodpovedá políčku time to live v IPv4 a určuje životnosť datagramu, presnejšie počet routrov, cez ktoré môže prejsť.
  • source address alebo zdrojová adresa je 128 bitová adresa zdrojovej stanice.
  • destination address alebo cieľová adresa je 128 bitová adresa cieľa (stanice alebo skupiny). Viac o adresácii v IPv6 sieťach bude spomenuté nižšie.

Môžete si všimnúť, že oproti protokolu IPv4 má hlavička IPv6 menej políčok. Svoj náprotivok nemajú v hlavnej hlavičke políčka pre kontrolný súčet, fragmentáciu a voľby. Všetky tieto zmeny znižujú výpočtové nároky na spracovanie datagramov na routroch.

Kontrolný súčet bol odstránený úplne ako nadbytočný a redundantný, keďže kontrola sa prevádza ako na spojovej, tak aj na transportnej vrstve.

Fragmentácia na routroch je v IPv6 neprípustná. Keď router zistí, že nevie ďalej poslať tak veľký datagram, namiesto fragmentácie tento datagram zahodí a pošle ICMPv6 správu, že datagram je príliš veľký a odosielateľ by mal posielať menšie datagramy. Cez rozširujúcu hlavičku je možné fragmentovať na zdrojovej stanici.

3.1  Adresácia v protokole IPv6

Adresy v protokole IPv6 majú 128 bitov. Zapisujú sa ako osem dvojbajtových slov v šestnástkovej sústave oddelených dvojbodkou. Napríklad fe80:0000:0000:0000:0221:5cff:fe64:d39a. Prvé dvojbajtové slovo fe80 v dvojkovej sústave vyzerá nasledovne 1111 1110 1000 0000, ostatné si môžete vyjadriť sami podľa známych prevodov medzi číselnými sústavami.

Okrem úplného tvaru IPv6 adresy máme možnosť aj skrátených vyjadrení. V nasledujúcej tabuľke označujú všetky riadky tú istú adresu.

tvar IPv6 adresy vysvetlenie
fe80:0000:0000:0000:0221:5cff:fe64:d39a úplný tvar, každá štvorica bitov je zobrazená ako číslica v šestnástkovej sústave
fe80:0:0:0:221:5cff:fe64:d39a odstránené úvodné nuly z každého dvojbajtového slova
fe80::221:5cff:fe64:d39a vyjadrenie :: znamená, že je potrebné doplniť toľko nulových dvojbajtových slov, aby bolo dokopy osem dvojbajtových slov; výraz :: sa môže v každej adrese použiť len raz
fe80::221:5cff:254.100.221.154 posledné dve dvojbajtové slová sú vyjadrené ako štyri jednobajtové slová v desiatkovej sústave oddelené bodkami; hovoríme o mixovanej notácii, keďže posledné 4 bajty vyzerajú ako IPv4 adresa

To, aká časť IPv6 adresy nás zaujíma (napríklad v smerovacej tabuľke) sa označuje podobne ako v IPv4 lomkou za IP adresou a predstavuje počet jednotiek v maske v dvojkovej sústave. Vyjadrenie cez masky v duchu ffff:ffff:ffff:ff00:: sa nepoužíva.

Podobne ako v IPv4 aj v IPv6 je niekoľko adries vyhradených na špeciálne účely.

  • Ako prvé uvedieme, že IPv6 nepozná broadcast, takže broadcastové IP adresy 255.255.255.225/32, 158.197.31.255/24 a podobne nemajú svoj náprotivok v IPv6. Ak chceme posielať nejakú správu viacerým, musíme použiť multicast.
  • 0:0:0:0:0:0:0:0/128 alebo aj ::/128 má rovnaký význam ako adresa 0.0.0.0 v IPv4, a určuje nešpecifikovanú adresu zdroja v lokálnej sieti – pozrite si minulú prednášku.
  • 0:0:0:0:0:0:0:1/128 alebo aj ::1/128 určuje localhost, a je ekvivalentom z 127.0.0.1 z IPv4.
  • 0:0:0:0:0:ffff:IPv4 adresa/128 alebo aj ::ffff:IPv4 adresa/128, napríklad ::ffff:158.197.31.4/128, slúži na reprezentáciu rozhraní s IPv4 adresami ako rozhraní s IPv6 adresami v SIIT (Stateless IP/ICMP Translation), ktoré sa veľmi nepresadilo (viac o prechode z IPv4 na IPv6 je popísané nižšie).
  • fe80::/10 (fe8X:hocičo, fe9X:hocičo, feaX:hocičo a febX:hocičo) – link-local – Lokálne adresy slúžia ako adresy pre lokálnu sieť a nemôžu prejsť routrom. Tieto adresy sú novinkou oproti čomukoľvek v IPv4. Tieto adresy si stanice prideľujú samy ako súčasť autokonfigurácie. Takto vygenerovaná IPv6 adresa sa dá používať na komunikáciu s počítačmi vo vnútri lokálnej siete. To znamená, že ak nejakí neskúsení používatelia vezmú niekoľko počítačov a napoja ich cez obyčajný switch, alebo dokonca na priamo, tieto počítače si sami nastavia svoje IPv6 adresy bez DHCP servera a bez potreby ručnej konfigurácie, a môžu začať komunikovať – hrať hry, zdieľať súbory a pod. Viac o autokonfigurácii nižšie.
  • fec0::/10 – site-local – Lokálny rozsah adries pre vnútro organizácií, ktorý by presne zodpovedal určeniu privátnych adries 10.0.0.0/8, 172.16.0.0/12 a 192.168.0.0/16, bol zrušený a nemá sa používať.
  • fc00::/7 – unique-local – Unikátne privátne adresy sú veľmi podobné „site-local“ adresám, ale majú oproti nim špeciálnu výhodu, a síce, že majú určené, akým spôsobom sa má generovať sieťový prefix pre tieto privátne IPv6 adresy – kombináciou MAC adresy, dátumu a hašovacej funkcie SHA1 – čo zabezpečuje vysokú pravdepodobnosť jedinečnosti tohto prefixu na celom internete (RFC 4193) (vyberá sa jedna z 2,2 biliónov možností). Príkladom využitia sú virtuálne privátne siete (VPN) bez potreby NATovania.
  • ff00::/8 sú určené pre multicast. Multicastová adresa nesmie byť pridelená žiadnemu rozhraniu.
    • ffX2:hocičo je multicast pre lokálnu sieť, ffX8:hocičo je multicast pre sieť vlastnej organizácie aj keď má vo vnútri viac podsietí. Tieto multicastové IP adresy si môžu nastavovať administrátori sami podľa ľubovôle, lebo tieto adresy nie sú prístupné z verejného internetu. Pre každý známejší protokol, ktorý v IPv4 používal broadcast je vyhradená dobre známa lokálna multicastová IPv6 adresa. Napríklad ak chceme kontaktovať DHCPv6 server môžeme použiť multicastovú adresu ff02::1:2, keďže ide o dobre známu lokálnu multicastovú IPv6 adresu, a datagramy s touto cieľovou adresou podľa štandardu spracúvajú všetky DHCPv6 servery a relay agenti lokálnej siete.
    • ffXe:hocičo je multicast pre celý Internet. Tieto adresy sú prideľované regionálnymi registrátormi pod organizáciou IANA (u nás RIPE NCC)
  • 2000::/3 (2xxx:hocičo, 3xxx:hocičo) – globálne adresy – Verejné unicastové (= na komunikáciu jedného s jedným) adresy určené pre adresovanie všetkých koncových uzlov. V ideálnom prípade by takúto IPv6 adresu malo mať každé zariadenie pripojené do internetu (už žiaden NAT).

Celá adresácia, vrátane týchto špeciálnych IPv6 adries je popísaná v RFC 4291. Ďalšie adresy na špecifické ciele spomenieme nižšie, môžete ich nájsť aj v RFC 5156.

3.2  Štruktúra globálnych unicastových IPv6 adries

V IPv4 sa identifikuje rozhranie zariadenia v sieti na základe takej dlhej časti IPv4 adresy, akú mu určuje maska. V unicastovej IPv6 adrese sa na identifikáciu rozhrania používa VŽDY posledných 64 bitov adresy, teda presne polovica celej adresy. IPv6 adresa je teda rozdelená na dve polovice: sieťovú časť a časť rozhrania. Kratšie masky sietí sa používajú vlastne iba v smerovacích tabuľkách routrov. Koncové siete by mali byť vždy s prefixom dĺžky 64 bitov.

Sieťový prefix je robený tak, aby delenie sietí na podsiete zodpovedalo deleniu podľa geografickej polohy podsietí – kratšie prefixy určujú kontinenty, dlhšie potom časti kontinentov, štáty, okresy, mestá, mestské časti, až tie najdlhšie (48 bitov) určujú koncových zákazníkov. Koncoví zákazníci majú k dispozícii ešte 16 bitov sieťovej časti na delenie svojej inštitúcie alebo domácnosti na ďalších až 65536 sietí.

Analógiou je poštová adresa, kde posledný riadok – názov štátu, v tomto prípade najkratší sufix adresy, určuje lokalizáciu hrubšie ako vyššie riadky (dlhší sufix) s lokálnejším charakterom (obec, ulica, osoba). Takéto hierarchické delenie adries podľa lokality umožňuje mať na routroch relatívne málo záznamov v smerovacích tabuľkách. Ľudovo povedané, jedným riadkom viem na routri v Košiciach vybaviť celú Áziu a ďalším celú Ameriku, ale na smerovanie do košických sídlisk a mestských častí už potrebujem viac riadkov s dlhšími prefixmi.

Ako vidno na obrázku, globálne unicastové adresy začínajú dvojkou (alebo trojkou, ktorá sa zatiaľ nezačala rozdeľovať), ktorá je nasledovaná 32 bitovým prefixom, ktorý rozdeľuje organizácia IANA spolu s 5 regionálnymi registrátormi – RIR – (RIPE NCC, ARIN, APNIC, AFRNIC, LACNIC), z ktorých každý spravuje jeden subkontinent sveta. Tieto prefixy sú rozdeľované lokálnym registrátorom (LIR), ktorí prideľujú prefixy dĺžky 48 bitov koncovým zákazníkom, ktorým tak ostáva ešte 16 bitov na realizáciu vlastných až do 65536 podsietí (Subnet ID) s prefixmi dĺžky 64 bitov. Niektorí zainteresovaní tvrdia, že prideľovať malým koncovým zákazníkom (domácnostiam) také krátke sieťové prefixy je zbytočné plytvanie a je možné, že sa pristúpi k tomu, aby boli takýmto malým koncovým zákazníkom prideľované prefixy dĺžky 56 bitov. Aj tak bude možné v každej domácnosti vytvoriť 256 podsietí, čo by malo v pohode stačiť.

3.3  Autokonfigurácia

SLAAC – Stateless Address Autoconfiguration, RFC 2462

Asi najradikálnejšou zmenou je spôsob prideľovania IPv6 adries koncovým staniciam. Samozrejme, je možné ručné statické prideľovanie adries, čo je využiteľné hlavne pre počítače, na ktoré existujú DNS záznamy. Pre pracovné stanice a iné koncové zariadenia je však vhodné prideliť IPv6 adresu automaticky. Pre IPv4 adresy celú réžiu prideľovania realizuje DHCP server. V prípade IPv6 adries je to pestrejšie. Celý proces prideľovania sa dá rozdeliť na pridelenie identifikátora rozhrania v sieti (Interface ID), pridelenie sieťovej časti adresy, default routra a lokálnych rekurzívnych DNS serverov.

Prideľovanie identifikátora rozhrania

Keďže na identifikáciu rozhraní v sieti je vyhradených až 64 bitov, tak teoreticky môžeme v každej sieti adresovať až 264 zariadení. Takéto množstvo zariadení v jedinej sieti samozrejme nebolo cieľom. Keď máme k dispozícii taký adresový priestor, je umožnené každému zariadeniu vytvoriť si jeden alebo viac sieťovo unikátnych identifikátorov bez centrálneho prideľovača.

Prvé riešenie nazvané IPv6 EUI-64 generuje unikátny identifikátor jednoducho tak, že využije unikátnosť MAC adresy, ktorá má dĺžku 48 bitov. Namapovať 48 bitov na 64 nie je žiaden problém, používa sa na to jednoduchý prevod, ktorý ukazuje nasledujúci obrázok.

Tento mechanizmus zaručuje jedinečnosť adresy, ale narúša súkromie, pretože generuje rovnaký identifikátor vo všetkých sieťach, kde sa toto zariadenie pripojí. Pohyb takého zariadenia je potom jednoducho sledovateľný (napr. na webovej stránke vieme zistiť, že z ktorých sietí sa dané zariadenie pripájalo)

Druhé riešenie Privacy extensions for stateless address autoconfiguration in IPv6 tento nedostatok úplne eliminuje. Jednoducho sa koncovky generujú cez pseudonáhodný generátor. Navyše, tieto koncovky sa pravidelne (každý deň) menia a jedna stanica môže používať viaceré naraz. V tomto prípade už je šanca, aj keď strašne malá, že dve zariadenia si zvolia ten istý identifikátor. Každá stanica si preto po vygenerovaní ešte overuje jedinečnosť vygenerovaného identifikátora cez detekciu duplicitných adries protokolom ICMPv6.

Postup autokonfigurácie IPv6 adresy

Pri napojení do siete si zariadenie samo vygeneruje link-local adresu fe80::identifikátor_rozhrania na základe niektorého zo spôsobov prideľovania identifikátora rozhrania. Následne si pomocou detekcie duplicitných adries zistí jednoznačnosť svojho identifikátora. Ak náhodou už v sieti niekto takýto identifikátor má, vygeneruje si iný.

Router v pravidelných intervaloch odosiela cez multicast do lokálnej siete oznámenia routra – router advertisement (typ ICMPv6 správy), v ktorých informuje zariadenia v sieti o svojej IPv6 adrese, aby si zariadenia vedeli nastaviť predvolenú bránu (default gateway) a o sieťovom prefixe, ktorý si má stanica nastaviť. Stanica, ktorá sa práve napojila, si môže zažiadať o okamžité zaslanie oznámenia routra cez požiadavku routru – router solicitation (typ ICMPv6 správy).

V oznámeniach routra sa nachádzajú dva príznaky M-managed a O-other. Ak je nastavený príznak M na 1, tak router informuje, že v sieti sa nachádza stavový DHCPv6 server, ktorý je potrebné kontaktovať kvôli ďalším potrebným nastaveniam. Ak je nastavený príznak O na 1, v sieti sa nachádza bezstavový DHCPv6 server. Ak sú oba príznaky vypnuté, t. j. nastavené na 0, v sieti sa (podľa routra) nenachádza DHCPv6 server. Stanica sa teda zariadi podľa týchto príznakov.

Najjednoduchší prípad, keď sú oba príznaky vynulované, predpokladá, že všetko potrebné na nakonfigurovanie je obsiahnuté v oznámeniach routra.

V prípade, že sme sa dozvedeli o prítomnosti bezstavového DHCPv6 servera, zistíme hlavne adresy lokálnych DNS serverov, ale aj napr. predvolené domény či NTP servery.

Stavový DHCPv6 server prideľuje okrem adries lokálnych DNS serverov aj celé IPv6 adresy s prefixom siete aj identifikátorom rozhrania. Pracuje teda podobne ako DHCP(v4) server s jedným rozdielom a to, že neposiela adresy predvolenej brány. Tá sa musí získať cez oznámenia samotného routra, ktorý je touto bránou. Môže sa zdať, že sa použitím stavového DHCPv6 servera popiera automatické generovanie identifikátora rozhrania, nie je to však pravda. Zariadenie si okrem pridelenej IPv6 adresy môže generovať aj ďalšie – napr. keď použije sieťový prefix zasielaný v oznámeniach routra spolu s vlastným vygenerovaným identifikátorom.

3.4  Prechod z IPv4 na IPv6

Prechod na IPv6 je náročný proces. Keďže do internetu je zapojených niekoľko miliárd zariadení s rôznym hardvérovým a softvérovým vybavením, nedá sa jednoducho spraviť to, že sa vyhlási deň a hodina, keď sa všetci prepnú na vyššiu verziu IP protokolu. Okrem operačných systémov koncových zariadení musia byť na prechod postupne pripravené aj všetky sieťové aplikácie a všetky routre. Tiež je potrebné vykonať príslušné zmeny aj na DNS serveroch. Je teda nutné riešiť to, aby bolo súčasne možné fungovať nad oboma protokolmi.

Najpravdepodobnejší scenár je, že všetky zariadenia postupne prejdú na tzv. dual-stack, čo znamená, že budú vedieť komunikovať protokolom IPv4 aj IPv6 a budú mať aj obe IP adresy, alebo namiesto IPv4 adresy nejakú špeciálnu IPv6 adresu, v ktorej je IPv4 adresa zakomponovaná. Keď už nastane takýto stav, postupne bude možné IPv4 adresy prestať používať a časom už budú všetky zariadenia komunikovať výhradne cez IPv6. Ale to je asi ešte dosť vzdialená budúcnosť.

Zavádzať siete s IPv6 adresami v súčasnosti je nutné tak, aby bolo možné komunikovať so zariadeniami, ktoré majú iba IPv4 adresy. Aj keby sme chceli komunikovať len s IPv6 sieťami, pravdepodobne sa nevyhneme tomu, že na ceste do cieľovej siete pôjdu naše IPv6 datagramy cez také routre, ktoré na základe IPv6 adresy nevedia smerovať a rozumejú iba IPv4 adresám v IPv4 hlavičkách.

Ak chceme komunikovať z IPv6 siete do IPv4 siete môžeme použiť niektorý z prekladových mechanizmov. Medzi menej úspešné patrí SIIT, v ktorom sa reprezentujú IPv4 adresy v IPv6 adresách v tvare „::FFFF:IPv4 adresa“, ktorá sa na routri na pomedzí IPv6 a IPv4 sietí transformuje na „IPv4 adresu“. Problém tohto riešenia je, na akú cieľovú IPv4 adresu je potrebné zaslať odpoveď. Úspešnejším je stavový prekladový mechanizmus nazvaný NAT64+DNS64. Tento preklad je podobný NAT-u z IPv4 s tým rozdielom, že preklad sa deje iba voči IPv4 cieľovým adresám. Postup je nasledovný: Ak sa počítač, ktorý má iba IPv6 adresu, spýta v DNS64 na AAAA záznam cieľovej stanice a táto stanica má iba A záznam, DNS64 vygeneruje IPv6 adresu v tvare „prefix64::IPv4adresa“. Keď stanica pošle takýto datagram, odchytí ho NAT64 router, ktorý spraví preklad cieľovej IPv6 na IPv4, a zmení aj zdrojovú IPv6 adresu na svoju IPv4 adresu a nový zdrojový port a odošle takýto IPv4 datagram do IPv4 infraštruktúry. Pri príchode odpovede spraví opačný preklad.

Na vyriešenie komunikácie medzi dvoma ostrovmi IPv6 infraštruktúry cez IPv4 časti internetu sa v súčasnosti využívajú rôzne tunelovacie techniky založené na tom, že celý IPv6 datagram sa na jednom mieste zabalí do IPv4 datagramu, ten cestuje bežným spôsobom IPv4 infraštruktúrou až k nejakému zariadeniu, ktoré rozbalí IPv4 datagram, a IPv6 datagram v ňom pošle ďalej k cieľu už IPv6 infraštruktúrou.

Týchto tunelovacích techník existuje niekoľko. Niektoré sa používajú viac, niektoré iba veľmi okrajovo.

Celkom úspešný je spôsob tunelovania konfigurovanými tunelmi, pri ktorých si je potrebné ručne nastaviť tunel od svojho prekladového 6na4 routra k cieľovému prekladovému 4na6 routru. Existuje aj niekoľko automatizovaných mechanizmov na vyhľadávanie vhodného cieľového prekladového 4na6 routra.

Jeden z najúspešnejších tunelovacích mechanizmov, ktorý sa označuje 6to4 (RFC 3056), robí automatický preklad IPv6 adries na IPv4 adresy podobne ako SIIT. Zvláda to bezstavovo, t.j. nemusí si pamätať preklady, ktoré realizoval v minulosti. Idea tohto prístupu sa zakladá na tom, že prijímajúca organizácia má aspoň jednu IPv4 adresu, od ktorej sa odvodia špeciálne IPv6 adresy s prefixom 2002:IPv4 adresa:/48 pre všetky stanice vo všetkých podsieťach organizácie (okrem toho môže mať aj normálne natívne globálne IPv6 adresy napríklad s prefixom 2001::/8). IPv6 datagram s cieľovou IPv6 adresou 2002:IPv4 adresa:/48 je na 6to4 routri zabalený do IPv4 datagramu s vyextrahovanou IPv4 adresou, ten putuje po IPv4 infraštruktúre až cieľovej IPv4 adrese 6to4 routra cieľovej organizácie kde je automaticky rozbalený a v ňom dopravený IPv6 datagram je zaslaný do vnútornej siete organizácie až k cieľovému zariadeniu na základe IPv6 adresy s prefixom 2002:IPv4 adresa:/48.

Trochu zložitá situácia v 6to4 je, keď zariadenie má iba IPv6 adresu s prefixom 2002::/16 a nemá natívnu globálnu IPv6 adresu (napr. s prefixom 2001::/16) a chce adresovať cieľové zariadenie, ktoré má len natívnu globálnu IPv6 adresu a nemá IPv6 adresu s prefixom 2002::/16. V takom prípade pri odchode cez jej hlavný router organizácie nie je možné zabaliť takýto datagram do IPv4 datagramu s IPv4 adresou cieľovej organizácie, keďže cieľová organizácia takú IPv4 adresu nemá. RFC 3068 to vyriešilo tak, že definovalo anycastovú IPv4 adresu 192.88.99.1, na ktorú to treba poslať, a ktorú odchytí najbližší 6to4 router s globálnou natívnou IPv6 adresou a uskutoční rozbalenie a zaslanie pôvodného datagramu IPv6 infraštruktúrou k cieľu.

Celá idea prechodu z IPv4 na IPv6 je popísaná v RFC 4038.

Na ďalšie hlbšie čítanie o IPv6 môže výborne poslúžiť voľne stiahnuteľná kniha Pavla Satrapu IPv6 a tiež skvelý seriál na serveri lupa.cz Pohněme s IPv6. Pre hlbšiu analýzu bezpečnosti a nasadenia IPv6 určenú pre správcov sietí vznikol seriál Bezpečné IPv6

Graf počtu IPv6 adries návštevníkov Google

4.  Úlohy a diskusia

  • Váš provider vám pridelil jedinú IP adresu 10.132.12.34, ale vy chcete do internetu zapojiť dva stolové počítače a jeden notebook, ktorý používate aj v škole. Takže si kúpite WiFi router. Musí mať tento WiFi router NAT? Musí mať tento router DHCP server? Ak chcete na jednom zo stolových počítačov prevádzkovať FTP server, viete to nastaviť tak, aby ho videli aj ostatní zákazníci tohto providera? Bude prístupný z Internetu?
  • Vo vašej privátnej sieti má vaša stanica IP adresu 192.168.0.1 a váš NAT router má na WAN rozhraní IP adresu 123.123.123.123 a LAN rozhraní 192.168.1.1 . Napíšte, aká je maska vašej privátnej siete. Predpokladajme, že vaša stanica pošle datagram s cieľovou adresou 158.197.31.4 na port 22. Aký riadok sa zapíše do prekladovej tabuľky NAT routra?
  • Vy aj váš kamarát v Austrálii ste obaja za svojimi NAT routrami. Váš kamarát vám chce poslať súbor na váš počítač s FTP serverom, ktorý ste si práve nainštalovali. Ako dosiahnete, aby sa mu podarilo na váš FTP server napojiť?
  • Predstavte si, že vám prestane fungovať internet. Ako zistíte, kde je chyba?
  • Ako vie program ping identifikovať, ku ktorému z odoslaných datagramov prišiel ICMP typu echo response?
  • Porovnajte hlavičky IPv4 a IPv6 datagramov, majú nejaké časti rovnaké?
  • Na sieťovú vrstvu prijímacej stanice prišiel datagram, ako vieme, o ktorú verziu IP protokolu ide?

zdroje: