{"id":337,"date":"2020-04-06T07:52:04","date_gmt":"2020-04-06T05:52:04","guid":{"rendered":"http:\/\/tech.sosthe.sk\/?p=337"},"modified":"2020-04-06T22:40:16","modified_gmt":"2020-04-06T20:40:16","slug":"4-3-sietovy-protokol-ip-verzie-6-ipv6","status":"publish","type":"post","link":"http:\/\/tech.sosthe.sk\/index.php\/2020\/04\/06\/4-3-sietovy-protokol-ip-verzie-6-ipv6\/","title":{"rendered":"4.8.\u2002Sie\u0165ov\u00fd protokol IP verzie 6 (IPv6)"},"content":{"rendered":"<p><strong>IPv6: internet protocol, version 6<\/strong>,\u00a0<a href=\"http:\/\/www.ietf.org\/rfc\/rfc2460.txt\">RFC 2460<\/a><\/p>\n<p>Protokol IPv4 sa postupne nahr\u00e1dza protokolom IPv6. Hlavnou zmenou je dlh\u0161ia IP adresa, ktor\u00e1 u\u017e nezaber\u00e1 32, ale a\u017e 128 bitov. T\u00fdm p\u00e1dom by u\u017e nikdy nemal vznikn\u00fa\u0165 stav, \u017ee sa vo\u013en\u00e9 IP adresy za\u010dn\u00fa r\u00fdchlo m\u00ed\u0148a\u0165, ako to za\u010d\u00edname poci\u0165ova\u0165 pri protokole IPv4. Samozrejme, u\u017e len kv\u00f4li dlh\u0161\u00edm adres\u00e1m, mus\u00ed IPv6 pou\u017e\u00edva\u0165 in\u00fa hlavi\u010dku ako IPv4.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter wp-image-338 size-full\" src=\"http:\/\/tech.sosthe.sk\/wp-content\/uploads\/2020\/04\/fig04_p02.gif\" alt=\"\" width=\"495\" height=\"257\" \/><\/p>\n<p>V\u00fdznam jednotliv\u00fdch \u010dast\u00ed hlavi\u010dky IPv6:<\/p>\n<ul>\n<li><strong>version<\/strong>, teda\u00a0<em>verzia<\/em>\u00a0IP protokolu m\u00e1 v sebe \u010d\u00edslo 6<\/li>\n<li><strong>traffic class<\/strong>, teda\u00a0<em>prenosov\u00e1 trieda<\/em>\u00a0ur\u010duje charakter d\u00e1t pren\u00e1\u0161an\u00fdch v tomto IPv6 datagrame a jej v\u00fdznam je podobn\u00fd ako\u00a0<em>type of service<\/em>\u00a0v IPv4. Ur\u010duje d\u00f4le\u017eitos\u0165 pren\u00e1\u0161an\u00fdch d\u00e1t, ktor\u00e1 sa m\u00f4\u017ee na routroch bra\u0165 do \u00favahy na \u201eprednostn\u00e9 vybavenie\u201c.<\/li>\n<li><strong>flow label<\/strong>\u00a0je 20 bitov\u00e1 inform\u00e1cia identifikuj\u00faca tok d\u00e1t. Toto \u010d\u00edslo e\u0161te nem\u00e1 presn\u00e9 ur\u010denie pou\u017eitia a m\u00e1 sa vy\u0161pecifikova\u0165 priebe\u017ene pod\u013ea potreby. Predpokladan\u00e9 pou\u017eitie je v kombin\u00e1cii s hodnotou\u00a0<em>traffic class<\/em>\u00a0pre identifikovanie multimedi\u00e1lnych pr\u00fadov d\u00e1t ako TV, r\u00e1di\u00e1, videokonferencie, alebo ako identifik\u00e1tor z\u00e1kazn\u00edka, ktor\u00fd si priplatil za \u0161peci\u00e1lnu prioritu svojich datagramov.<\/li>\n<li><strong>payload length<\/strong>\u00a0predstavuje ve\u013ekos\u0165 tela datagramu v bajtoch bez hlavi\u010dky, ktor\u00e1 m\u00e1 v\u017edy 40 bajtov.<\/li>\n<li><strong>next header<\/strong>\u00a0zodpoved\u00e1 pol\u00ed\u010dku\u00a0<em>protocol<\/em>\u00a0v IPv4 a ur\u010duje, \u017ee hlavi\u010dka ak\u00e9ho protokolu sa nach\u00e1dza v tele datagramu, teda hne\u010f za hlavnou hlavi\u010dkou Ipv4 datagramu. Typicky to je TCP alebo UDP hlavi\u010dka, ale m\u00f4\u017eu to by\u0165 aj in\u00e9 hlavi\u010dky ako ICMP \u010di dokonca hlavi\u010dka protokolu IPv4 pren\u00e1\u0161an\u00e1 cez IPv6. Novinkou oproti IPv4 je, \u017ee nasleduj\u00facou hlavi\u010dkou m\u00f4\u017ee by\u0165 aj roz\u0161iruj\u00faca hlavi\u010dka. IPv6 m\u00e1 definovan\u00fdch celkovo 8 roz\u0161iruj\u00facich hlavi\u010diek. Je mo\u017en\u00e9 pou\u017ei\u0165 \u017eiadnu, niektor\u00e9, aj v\u0161etky. Tieto hlavi\u010dky s\u00fa za sebou zre\u0165azen\u00e9 cez \u201enext header\u201c. Ich zameranie je r\u00f4zne \u2013 na fragment\u00e1ciu, \u0161ifrovanie cez IPsec, mobilitu a in\u00e9.<\/li>\n<li><strong>hop limit<\/strong>\u00a0zodpoved\u00e1 pol\u00ed\u010dku\u00a0<em>time to live<\/em>\u00a0v IPv4 a ur\u010duje \u017eivotnos\u0165 datagramu, presnej\u0161ie po\u010det routrov, cez ktor\u00e9 m\u00f4\u017ee prejs\u0165.<\/li>\n<li><strong>source address<\/strong>\u00a0alebo\u00a0<em>zdrojov\u00e1 adresa<\/em>\u00a0je 128 bitov\u00e1 adresa zdrojovej stanice.<\/li>\n<li><strong>destination address<\/strong>\u00a0alebo\u00a0<em>cie\u013eov\u00e1 adresa<\/em>\u00a0je 128 bitov\u00e1 adresa cie\u013ea (stanice alebo skupiny). Viac o adres\u00e1cii v IPv6 sie\u0165ach bude spomenut\u00e9 ni\u017e\u0161ie.<\/li>\n<\/ul>\n<p>M\u00f4\u017eete si v\u0161imn\u00fa\u0165 \u017ee oproti protokolu IPv4 m\u00e1 hlavi\u010dka IPv6 menej pol\u00ed\u010dok. Svoj n\u00e1protivok nemaj\u00fa v hlavnej hlavi\u010dke pol\u00ed\u010dka pre kontroln\u00fd s\u00fa\u010det, fragment\u00e1ciu a vo\u013eby. V\u0161etky tieto zmeny zni\u017euj\u00fa v\u00fdpo\u010dtov\u00e9 n\u00e1roky na spracovanie datagramov na routroch.<\/p>\n<p>Kontroln\u00fd s\u00fa\u010det bol odstr\u00e1nen\u00fd \u00faplne ako nadbyto\u010dn\u00fd a redundantn\u00fd, ke\u010f\u017ee kontrola sa prev\u00e1dza ako na spojovej, tak aj na transportnej vrstve.<\/p>\n<p>Fragment\u00e1cia na routroch je v IPv6 nepr\u00edpustn\u00e1. Ke\u010f router zist\u00ed, \u017ee nevie \u010falej posla\u0165 tak ve\u013ek\u00fd datagram, namiesto fragment\u00e1cie tento datagram zahod\u00ed a po\u0161le ICMPv6 spr\u00e1vu, \u017ee datagram je pr\u00edli\u0161 ve\u013ek\u00fd a odosielate\u013e by mal posiela\u0165 men\u0161ie datagramy. Cez roz\u0161iruj\u00facu hlavi\u010dku je mo\u017en\u00e9 fragmentova\u0165 na zdrojovej stanici.<\/p>\n<h3>4.8.1\u2002 Adres\u00e1cia v protokole IPv6<\/h3>\n<p>Adresy v protokole IPv6 maj\u00fa 128 bitov. Zapisuj\u00fa sa ako osem dvojbajtov\u00fdch slov v \u0161estn\u00e1stkovej s\u00fastave oddelen\u00fdch dvojbodkou. Napr\u00edklad fe80:0000:0000:0000:0221:5cff:fe64:d39a. Prv\u00e9 dvojbajtov\u00e9 slovo fe80 v dvojkovej s\u00fastave vyzer\u00e1 nasledovne 1111 1110 1000 0000, ostatn\u00e9 si m\u00f4\u017eete vyjadri\u0165 sami pod\u013ea zn\u00e1mych prevodov medzi \u010d\u00edseln\u00fdmi s\u00fastavami.<\/p>\n<p>Okrem \u00fapln\u00e9ho tvaru IPv6 adresy m\u00e1me mo\u017enos\u0165 aj skr\u00e1ten\u00fdch vyjadren\u00ed. V nasleduj\u00facej tabu\u013eke ozna\u010duj\u00fa v\u0161etky riadky t\u00fa ist\u00fa adresu.<\/p>\n<figure class=\"wp-block-table\">\n<table>\n<tbody>\n<tr>\n<td>tvar IPv6 adresy<\/td>\n<td>vysvetlenie<\/td>\n<\/tr>\n<tr>\n<td>fe80:0000:0000:0000:0221:5cff:fe64:d39a<\/td>\n<td>\u00fapln\u00fd tvar, ka\u017ed\u00e1 \u0161tvorica bitov je zobrazen\u00e1 ako \u010d\u00edslica v \u0161estn\u00e1stkovej s\u00fastave<\/td>\n<\/tr>\n<tr>\n<td>fe80:0:0:0:221:5cff:fe64:d39a<\/td>\n<td>odstr\u00e1nen\u00e9 \u00favodn\u00e9 nuly z ka\u017ed\u00e9ho dvojbajtov\u00e9ho slova<\/td>\n<\/tr>\n<tr>\n<td>fe80::221:5cff:fe64:d39a<\/td>\n<td>vyjadrenie :: znamen\u00e1, \u017ee je potrebn\u00e9 doplni\u0165 to\u013eko nulov\u00fdch dvojbajtov\u00fdch slov, aby bolo dokopy osem dvojbajtov\u00fdch slov; v\u00fdraz :: sa m\u00f4\u017ee v ka\u017edej adrese pou\u017ei\u0165 len raz<\/td>\n<\/tr>\n<tr>\n<td>fe80::221:5cff:254.100.221.154<\/td>\n<td>posledn\u00e9 dve dvojbajtov\u00e9 slov\u00e1 s\u00fa vyjadren\u00e9 ako \u0161tyri jednobajtov\u00e9 slov\u00e1 v desiatkovej s\u00fastave oddelen\u00e9 bodkami; hovor\u00edme o mixovanej not\u00e1cii, ke\u010f\u017ee posledn\u00e9 4 bajty vyzeraj\u00fa ako IPv4 adresa<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n<p>To, ak\u00e1 \u010das\u0165 IPv6 adresy n\u00e1s zauj\u00edma (napr\u00edklad v smerovacej tabu\u013eke) sa ozna\u010duje podobne ako v IPv4 lomkou za IP adresou a predstavuje po\u010det jednotiek v maske v dvojkovej s\u00fastave. Vyjadrenie cez masky v duchu ffff:ffff:ffff:ff00:: sa nepou\u017e\u00edva.<\/p>\n<p>Podobne ako v IPv4 aj v IPv6 je nieko\u013eko adries vyhraden\u00fdch na \u0161peci\u00e1lne \u00fa\u010dely.<\/p>\n<ul>\n<li>Ako prv\u00e9 uvedieme, \u017ee\u00a0<strong>IPv6 nepozn\u00e1 broadcast<\/strong>, tak\u017ee broadcastov\u00e9 IP adresy 255.255.255.225\/32, 158.197.31.255\/24 a podobne nemaj\u00fa svoj n\u00e1protivok v IPv6. Ak chceme posiela\u0165 nejak\u00fa spr\u00e1vu viacer\u00fdm, mus\u00edme pou\u017ei\u0165 multicast.<\/li>\n<li><strong>0:0:0:0:0:0:0:0\/128<\/strong>\u00a0alebo aj\u00a0<strong>::\/128<\/strong>\u00a0m\u00e1 rovnak\u00fd v\u00fdznam ako adresa 0.0.0.0 v IPv4, a ur\u010duje ne\u0161pecifikovan\u00fa adresu zdroja v lok\u00e1lnej sieti \u2013 pozrite si minul\u00fa predn\u00e1\u0161ku.<\/li>\n<li><strong>0:0:0:0:0:0:0:1\/128<\/strong>\u00a0alebo aj\u00a0<strong>::1\/128<\/strong>\u00a0ur\u010duje localhost, a je ekvivalentom z 127.0.0.1 z IPv4.<\/li>\n<li><strong>0:0:0:0:0:ffff:IPv4 adresa\/128<\/strong>\u00a0alebo aj\u00a0<strong>::ffff:IPv4 adresa\/128<\/strong>, napr\u00edklad\u00a0<em>::ffff:158.197.31.4\/128<\/em>, sl\u00fa\u017ei na reprezent\u00e1ciu rozhran\u00ed s IPv4 adresami ako rozhran\u00ed s IPv6 adresami v\u00a0<a href=\"http:\/\/www.ietf.org\/rfc\/rfc2765.txt\">SIIT<\/a>\u00a0(Stateless IP\/ICMP Translation), ktor\u00e9 sa ve\u013emi nepresadilo (viac o prechode z IPv4 na IPv6 je pop\u00edsan\u00e9 ni\u017e\u0161ie).<\/li>\n<li><strong>fe80::\/10<\/strong>\u00a0(fe8X:hoci\u010do, fe9X:hoci\u010do, feaX:hoci\u010do a febX:hoci\u010do) \u2013\u00a0<strong>link-local<\/strong>\u00a0\u2013 Lok\u00e1lne adresy sl\u00fa\u017eia ako adresy pre lok\u00e1lnu sie\u0165 a nem\u00f4\u017eu prejs\u0165 routrom. Tieto adresy s\u00fa novinkou oproti \u010domuko\u013evek v IPv4. Tieto adresy si stanice pride\u013euj\u00fa samy ako s\u00fa\u010das\u0165 autokonfigur\u00e1cie. Takto vygenerovan\u00e1 IPv6 adresa sa d\u00e1 pou\u017e\u00edva\u0165 na komunik\u00e1ciu s po\u010d\u00edta\u010dmi vo vn\u00fatri lok\u00e1lnej siete. To znamen\u00e1, \u017ee ak nejak\u00ed nesk\u00fasen\u00ed pou\u017e\u00edvatelia vezm\u00fa nieko\u013eko po\u010d\u00edta\u010dov a napoja ich cez oby\u010dajn\u00fd switch, alebo dokonca na priamo, tieto po\u010d\u00edta\u010de si sami nastavia svoje IPv6 adresy bez DHCP servera a bez potreby ru\u010dnej konfigur\u00e1cie, a m\u00f4\u017eu za\u010da\u0165 komunikova\u0165 \u2013 hra\u0165 hry, zdie\u013ea\u0165 s\u00fabory a pod. Viac o autokonfigur\u00e1cii ni\u017e\u0161ie.<\/li>\n<li><strong>fec0::\/10<\/strong>\u00a0\u2013\u00a0<strong>site-local<\/strong>\u00a0\u2013 Lok\u00e1lny rozsah adries pre vn\u00fatro organiz\u00e1ci\u00ed, ktor\u00fd by presne zodpovedal ur\u010deniu priv\u00e1tnych adries 10.0.0.0\/8, 172.16.0.0\/12 a 192.168.0.0\/16, bol zru\u0161en\u00fd a nem\u00e1 sa pou\u017e\u00edva\u0165.<\/li>\n<li><strong>fc00::\/7<\/strong>\u00a0\u2013\u00a0<strong>unique-local<\/strong>\u00a0\u2013 Unik\u00e1tne priv\u00e1tne adresy s\u00fa ve\u013emi podobn\u00e9 \u201esite-local\u201c adres\u00e1m, ale maj\u00fa oproti nim \u0161peci\u00e1lnu v\u00fdhodu, a s\u00edce, \u017ee maj\u00fa ur\u010den\u00e9, ak\u00fdm sp\u00f4sobom sa m\u00e1 generova\u0165 sie\u0165ov\u00fd prefix pre tieto priv\u00e1tne IPv6 adresy \u2013 kombin\u00e1ciou MAC adresy, d\u00e1tumu a ha\u0161ovacej funkcie SHA1 \u2013 \u010do zabezpe\u010duje vysok\u00fa pravdepodobnos\u0165 jedine\u010dnosti tohto prefixu na celom internete (<a href=\"http:\/\/www.ietf.org\/rfc\/rfc4193.txt\">RFC 4193<\/a>) (vyber\u00e1 sa jedna z 2,2 bili\u00f3nov mo\u017enost\u00ed). Pr\u00edkladom vyu\u017eitia s\u00fa virtu\u00e1lne priv\u00e1tne siete (VPN) bez potreby NATovania.<\/li>\n<li><strong>ff00::\/8<\/strong>\u00a0s\u00fa ur\u010den\u00e9 pre multicast. Multicastov\u00e1 adresa nesmie by\u0165 pridelen\u00e1 \u017eiadnemu rozhraniu.\n<ul>\n<li><strong>ffX2:hoci\u010do<\/strong>\u00a0je multicast pre lok\u00e1lnu sie\u0165,\u00a0<strong>ffX8:hoci\u010do<\/strong>\u00a0je multicast pre sie\u0165 vlastnej organiz\u00e1cie aj ke\u010f m\u00e1 vo vn\u00fatri viac podsiet\u00ed. Tieto multicastov\u00e9 IP adresy si m\u00f4\u017eu nastavova\u0165 administr\u00e1tori sami pod\u013ea \u013eubov\u00f4le, lebo tieto adresy nie s\u00fa pr\u00edstupn\u00e9 z verejn\u00e9ho internetu. Pre ka\u017ed\u00fd zn\u00e1mej\u0161\u00ed protokol, ktor\u00fd v IPv4 pou\u017e\u00edval broadcast je vyhraden\u00e1 dobre zn\u00e1ma lok\u00e1lna multicastov\u00e1 IPv6 adresa. Napr\u00edklad ak chceme kontaktova\u0165 DHCPv6 server m\u00f4\u017eeme pou\u017ei\u0165 multicastov\u00fa adresu ff02::1:2, ke\u010f\u017ee ide o dobre zn\u00e1mu lok\u00e1lnu multicastov\u00fa IPv6 adresu, a datagramy s touto cie\u013eovou adresou pod\u013ea \u0161tandardu sprac\u00favaj\u00fa v\u0161etky DHCPv6 servery a relay agenti lok\u00e1lnej siete.<\/li>\n<li><strong>ffXe:hoci\u010do<\/strong>\u00a0je multicast pre cel\u00fd Internet. Tieto adresy s\u00fa pride\u013eovan\u00e9 region\u00e1lnymi registr\u00e1tormi pod organiz\u00e1ciou IANA (u n\u00e1s RIPE NCC)<\/li>\n<\/ul>\n<\/li>\n<li><strong>2000::\/3<\/strong>\u00a0(2xxx:hoci\u010do, 3xxx:hoci\u010do) \u2013 glob\u00e1lne adresy \u2013 Verejn\u00e9 unicastov\u00e9 (= na komunik\u00e1ciu jedn\u00e9ho z jedn\u00fdm) adresy ur\u010den\u00e9 pre adresovanie v\u0161etk\u00fdch koncov\u00fdch uzlov. V ide\u00e1lnom pr\u00edpade by tak\u00fato IPv6 adresu malo ma\u0165 ka\u017ed\u00e9 zariadenie pripojen\u00e9 do internetu (u\u017e \u017eiaden NAT).<\/li>\n<\/ul>\n<p>Cel\u00e1 adres\u00e1cia, vr\u00e1tane t\u00fdchto \u0161peci\u00e1lnych IPv6 adries je pop\u00edsan\u00e1 v\u00a0<a href=\"http:\/\/www.ietf.org\/rfc\/rfc4291.txt\">RFC 4291<\/a>. \u010eal\u0161ie adresy na \u0161pecifick\u00e9 ciele spomenieme ni\u017e\u0161ie, m\u00f4\u017eete ich n\u00e1js\u0165 aj v\u00a0<a href=\"http:\/\/www.ietf.org\/rfc\/rfc5156.txt\">RFC 5156<\/a>.<\/p>\n<h3>4.8.2\u2002 \u0160trukt\u00fara glob\u00e1lnych unicastov\u00fdch IPv6 adries<\/h3>\n<p>V IPv4 sa identifikuje rozhranie zariadenia v sieti na z\u00e1klade takej dlhej \u010dasti IPv4 adresy, ak\u00fa mu ur\u010duje maska. V unicastovej IPv6 adrese sa na identifik\u00e1ciu rozhrania pou\u017e\u00edva V\u017dDY posledn\u00fdch 64 bitov adresy, teda presne polovica celej adresy. IPv6 adresa je teda rozdelen\u00e1 na dve polovice: sie\u0165ov\u00fa \u010das\u0165 a \u010das\u0165 rozhrania. Krat\u0161ie masky siet\u00ed sa pou\u017e\u00edvaj\u00fa vlastne iba v smerovac\u00edch tabu\u013ek\u00e1ch routrov. Koncov\u00e9 siete by mali by\u0165 v\u017edy s prefixom d\u013a\u017eky 64 bitov.<\/p>\n<p>Sie\u0165ov\u00fd prefix je roben\u00fd tak, aby delenie siet\u00ed na podsiete zodpovedalo deleniu pod\u013ea geografickej polohy podsiet\u00ed \u2013 krat\u0161ie prefixy ur\u010duj\u00fa kontinenty, dlh\u0161ie potom \u010dasti kontinentov, \u0161t\u00e1ty, okresy, mest\u00e1, mestsk\u00e9 \u010dasti, a\u017e tie najdlh\u0161ie (48 bitov) ur\u010duj\u00fa koncov\u00fdch z\u00e1kazn\u00edkov. Koncov\u00ed z\u00e1kazn\u00edci maj\u00fa k dispoz\u00edcii e\u0161te 16 bitov sie\u0165ovej \u010dasti na delenie svojej in\u0161tit\u00facie alebo dom\u00e1cnosti na \u010fal\u0161\u00edch a\u017e 65536 siet\u00ed.<\/p>\n<p>Anal\u00f3giou je po\u0161tov\u00e1 adresa, kde posledn\u00fd riadok \u2013 n\u00e1zov \u0161t\u00e1tu, v tomto pr\u00edpade najkrat\u0161\u00ed sufix adresy, ur\u010duje lokaliz\u00e1ciu hrub\u0161ie ako vy\u0161\u0161ie riadky (dlh\u0161\u00ed sufix) s lok\u00e1lnej\u0161\u00edm charakterom (obec, ulica, osoba). Tak\u00e9to hierarchick\u00e9 delenie adries pod\u013ea lokality umo\u017e\u0148uje ma\u0165 na routroch relat\u00edvne m\u00e1lo z\u00e1znamov v smerovac\u00edch tabu\u013ek\u00e1ch. \u013dudovo povedan\u00e9, jedn\u00fdm riadkom viem na routri v Ko\u0161iciach vybavi\u0165 cel\u00fa \u00c1ziu a \u010fal\u0161\u00edm cel\u00fa Ameriku, ale na smerovanie do ko\u0161ick\u00fdch s\u00eddlisk a mestsk\u00fdch \u010dast\u00ed u\u017e potrebujem viac riadkov s dlh\u0161\u00edmi prefixmi.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-339 size-full aligncenter\" src=\"http:\/\/tech.sosthe.sk\/wp-content\/uploads\/2020\/04\/IPv6unicast.png\" alt=\"\" width=\"765\" height=\"182\" srcset=\"http:\/\/tech.sosthe.sk\/wp-content\/uploads\/2020\/04\/IPv6unicast.png 765w, http:\/\/tech.sosthe.sk\/wp-content\/uploads\/2020\/04\/IPv6unicast-300x71.png 300w\" sizes=\"(max-width: 765px) 100vw, 765px\" \/><\/p>\n<p>Ako vidno na obr\u00e1zku, glob\u00e1lne unicastov\u00e9 adresy za\u010d\u00ednaj\u00fa dvojkou (alebo trojkou, ktor\u00e1 sa zatia\u013e neza\u010dala rozde\u013eova\u0165), ktor\u00e1 je nasledovan\u00e1 32 bitov\u00fdm prefixom, ktor\u00fd rozde\u013euje organiz\u00e1cia IANA spolu s 5 region\u00e1lnymi registr\u00e1tormi \u2013 RIR \u2013 (RIPE NCC, ARIN, APNIC, AFRNIC, LACNIC), z ktor\u00fdch ka\u017ed\u00fd spravuje jeden subkontinent sveta. Tieto prefixy s\u00fa rozde\u013eovan\u00e9 lok\u00e1lnym registr\u00e1torom (LIR), ktor\u00ed pride\u013euj\u00fa prefixy d\u013a\u017eky 48 bitov koncov\u00fdm z\u00e1kazn\u00edkom, ktor\u00fdm tak ost\u00e1va e\u0161te 16 bitov na realiz\u00e1ciu vlastn\u00fdch a\u017e do 65536 podsiet\u00ed (Subnet ID) s prefixmi d\u013a\u017eky 64 bitov. Niektor\u00ed zainteresovan\u00ed tvrdia, \u017ee pride\u013eova\u0165 mal\u00fdm koncov\u00fdm z\u00e1kazn\u00edkom (dom\u00e1cnostiam) tak\u00e9 kr\u00e1tke sie\u0165ov\u00e9 prefixy je zbyto\u010dn\u00e9 plytvanie a je mo\u017en\u00e9, \u017ee sa prist\u00fapi k tomu, aby boli tak\u00fdmto mal\u00fdm koncov\u00fdm z\u00e1kazn\u00edkom pride\u013eovan\u00e9 prefixy d\u013a\u017eky 56 bitov. Aj tak bude mo\u017en\u00e9 v ka\u017edej dom\u00e1cnosti vytvori\u0165 256 podsiet\u00ed, \u010do by malo v pohode sta\u010di\u0165.<\/p>\n<h3>4.8.3\u2002 Autokonfigur\u00e1cia<\/h3>\n<p><strong>SLAAC \u2013 Stateless Address Autoconfiguration<\/strong>,\u00a0<a href=\"http:\/\/www.ietf.org\/rfc\/rfc2462.txt\">RFC 2462<\/a><\/p>\n<p>Asi najradik\u00e1lnej\u0161ou zmenou je sp\u00f4sob pride\u013eovania IPv6 adries koncov\u00fdm staniciam. Samozrejme, je mo\u017en\u00e9 ru\u010dn\u00e9 statick\u00e9 pride\u013eovanie adries, \u010do je vyu\u017eite\u013en\u00e9 hlavne pre po\u010d\u00edta\u010de, na ktor\u00e9 existuj\u00fa DNS z\u00e1znamy. Pre pracovn\u00e9 stanice a in\u00e9 koncov\u00e9 zariadenia je v\u0161ak vhodn\u00e9 prideli\u0165 IPv6 adresu automaticky. Pre IPv4 adresy cel\u00fa r\u00e9\u017eiu pride\u013eovania realizuje DHCP server. V pr\u00edpade IPv6 adries je to pestrej\u0161ie. Cel\u00fd proces pride\u013eovania sa d\u00e1 rozdeli\u0165 na pridelenie identifik\u00e1tora rozhrania v sieti (Interface ID), pridelenie sie\u0165ovej \u010dasti adresy, default routra a lok\u00e1lnych rekurz\u00edvnych DNS serverov.<\/p>\n<h3>Pride\u013eovanie identifik\u00e1tora rozhrania<\/h3>\n<p>Ke\u010f\u017ee na identifik\u00e1ciu rozhran\u00ed v sieti je vyhraden\u00fdch a\u017e 64 bitov, tak teoreticky m\u00f4\u017eeme v ka\u017edej sieti adresova\u0165 a\u017e 2<sup>64<\/sup>\u00a0zariaden\u00ed. Tak\u00e9to mno\u017estvo zariaden\u00ed v jedinej sieti samozrejme nebolo cie\u013eom. Ke\u010f m\u00e1me k dispoz\u00edcii tak\u00fd adresov\u00fd priestor, je umo\u017enen\u00e9 ka\u017ed\u00e9mu zariadeniu vytvori\u0165 si jeden alebo viac sie\u0165ovo unik\u00e1tnych identifik\u00e1torov bez centr\u00e1lneho pride\u013eova\u010da.<\/p>\n<p>Prv\u00e9 rie\u0161enie nazvan\u00e9\u00a0<strong>IPv6 EUI-64<\/strong>\u00a0generuje unik\u00e1tny identifik\u00e1tor jednoducho tak, \u017ee vyu\u017eije unik\u00e1tnos\u0165 MAC adresy, ktor\u00e1 m\u00e1 d\u013a\u017eku 48 bitov. Namapova\u0165 48 bitov na 64 nie je \u017eiaden probl\u00e9m, pou\u017e\u00edva sa na to jednoduch\u00fd prevod, ktor\u00fd ukazuje nasleduj\u00faci obr\u00e1zok.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter wp-image-340 size-full\" src=\"http:\/\/tech.sosthe.sk\/wp-content\/uploads\/2020\/04\/eui-64.png\" alt=\"\" width=\"800\" height=\"189\" srcset=\"http:\/\/tech.sosthe.sk\/wp-content\/uploads\/2020\/04\/eui-64.png 800w, http:\/\/tech.sosthe.sk\/wp-content\/uploads\/2020\/04\/eui-64-300x71.png 300w, http:\/\/tech.sosthe.sk\/wp-content\/uploads\/2020\/04\/eui-64-768x181.png 768w\" sizes=\"(max-width: 800px) 100vw, 800px\" \/><\/p>\n<p>Tento mechanizmus zaru\u010duje jedine\u010dnos\u0165 adresy, ale nar\u00fa\u0161a s\u00fakromie, preto\u017ee generuje rovnak\u00fd identifik\u00e1tor vo v\u0161etk\u00fdch sie\u0165ach, kde sa toto zariadenie pripoj\u00ed. Pohyb tak\u00e9ho zariadenia je potom jednoducho sledovate\u013en\u00fd (napr. na webovej str\u00e1nke vieme zisti\u0165, \u017ee z ktor\u00fdch siet\u00ed sa dan\u00e9 zariadenie prip\u00e1jalo)<\/p>\n<p>Druh\u00e9 rie\u0161enie\u00a0<strong>Privacy extensions for stateless address autoconfiguration in IPv6<\/strong>\u00a0tento nedostatok \u00faplne eliminuje. Jednoducho sa koncovky generuj\u00fa cez pseudon\u00e1hodn\u00fd gener\u00e1tor. Navy\u0161e, tieto koncovky sa pravidelne (ka\u017ed\u00fd de\u0148) menia a jedna stanica m\u00f4\u017ee pou\u017e\u00edva\u0165 viacer\u00e9 naraz. V tomto pr\u00edpade u\u017e je \u0161anca, aj ke\u010f stra\u0161ne mal\u00e1, \u017ee dve zariadenia si zvolia ten ist\u00fd identifik\u00e1tor. Ka\u017ed\u00e1 stanica si preto po vygenerovan\u00ed e\u0161te overuje jedine\u010dnos\u0165 vygenerovan\u00e9ho identifik\u00e1tora cez detekciu duplicitn\u00fdch adries protokolom ICMPv6.<\/p>\n<h3>Postup autokonfigur\u00e1cie IPv6 adresy<\/h3>\n<p>Pri napojen\u00ed do siete si zariadenie samo vygeneruje link-local adresu fe80::identifik\u00e1tor_rozhrania na z\u00e1klade niektor\u00e9ho zo sp\u00f4sobov pride\u013eovania identifik\u00e1tora rozhrania. N\u00e1sledne si pomocou detekcie duplicitn\u00fdch adries zist\u00ed jednozna\u010dnos\u0165 svojho identifik\u00e1tora. Ak n\u00e1hodou u\u017e v sieti niekto tak\u00fdto identifik\u00e1tor m\u00e1, vygeneruje si in\u00fd.<\/p>\n<p>Router v pravideln\u00fdch intervaloch odosiela cez multicast do lok\u00e1lnej siete\u00a0<strong>ozn\u00e1menia routra \u2013 router advertisement<\/strong>\u00a0(typ ICMPv6 spr\u00e1vy), v ktor\u00fdch informuje zariadenia v sieti o svojej IPv6 adrese, aby si zariadenia vedeli nastavi\u0165 predvolen\u00fa br\u00e1nu (default gateway) a o sie\u0165ovom prefixe, ktor\u00fd si m\u00e1 stanica nastavi\u0165. Stanica, ktor\u00e1 sa pr\u00e1ve napojila, si m\u00f4\u017ee za\u017eiada\u0165 o okam\u017eit\u00e9 zaslanie ozn\u00e1menia routra cez\u00a0<strong>po\u017eiadavku routru \u2013 router solicitation<\/strong>\u00a0(typ ICMPv6 spr\u00e1vy).<\/p>\n<p>V ozn\u00e1meniach routra sa nach\u00e1dzaj\u00fa dva pr\u00edznaky M-managed a O-other. Ak je nastaven\u00fd pr\u00edznak M na 1, tak router informuje, \u017ee v sieti sa nach\u00e1dza stavov\u00fd DHCPv6 server, ktor\u00fd je potrebn\u00e9 kontaktova\u0165 kv\u00f4li \u010fal\u0161\u00edm potrebn\u00fdm nastaveniam. Ak je nastaven\u00fd pr\u00edznak O na 1, v sieti sa nach\u00e1dza bezstavov\u00fd DHCPv6 server. Ak s\u00fa oba pr\u00edznaky vypnut\u00e9, t. j. nastaven\u00e9 na 0, v sieti sa (pod\u013ea routra) nenach\u00e1dza DHCPv6\u00a0server. Stanica sa teda zariadi pod\u013ea t\u00fdchto pr\u00edznakov.<\/p>\n<p>Najjednoduch\u0161\u00ed pr\u00edpad, ke\u010f s\u00fa oba pr\u00edznaky vynulovan\u00e9, predpoklad\u00e1, \u017ee v\u0161etko potrebn\u00e9 na nakonfigurovanie je obsiahnut\u00e9 v ozn\u00e1meniach routra.<\/p>\n<p>V pr\u00edpade, \u017ee sme sa dozvedeli o pr\u00edtomnosti bezstavov\u00e9ho DHCPv6 servera, zist\u00edme hlavne adresy lok\u00e1lnych DNS serverov, ale aj napr. predvolen\u00e9 dom\u00e9ny \u010di NTP servery.<\/p>\n<p>Stavov\u00fd DHCPv6 server pride\u013euje okrem adries lok\u00e1lnych DNS serverov aj cel\u00e9 IPv6 adresy s prefixom siete aj identifik\u00e1torom rozhrania. Pracuje teda podobne ako DHCP(v4) server s jedn\u00fdm rozdielom, a to \u017ee neposiela adresy predvolenej br\u00e1ny. T\u00e1 sa mus\u00ed z\u00edska\u0165 cez ozn\u00e1menia samotn\u00e9ho routra, ktor\u00fd je touto br\u00e1nou. M\u00f4\u017ee sa zda\u0165, \u017ee sa pou\u017eit\u00edm stavov\u00e9ho DHCPv6 servera popiera automatick\u00e9 generovanie identifik\u00e1tora rozhrania, nie je to v\u0161ak pravda. Zariadenie si okrem pridelenej IPv6 adresy m\u00f4\u017ee generova\u0165 aj \u010fal\u0161ie \u2013 napr. ke\u010f pou\u017eije sie\u0165ov\u00fd prefix zasielan\u00fd v ozn\u00e1meniach routra spolu s vlastn\u00fdm vygenerovan\u00fdm identifik\u00e1torom.<\/p>\n<h3>4.8.4\u2002 Prechod z IPv4 na IPv6<\/h3>\n<p>Prechod na IPv6 je n\u00e1ro\u010dn\u00fd proces. Ke\u010f\u017ee do internetu je zapojen\u00fdch nieko\u013eko mili\u00e1rd zariaden\u00ed s r\u00f4znym hardv\u00e9rov\u00fdm a softv\u00e9rov\u00fdm vybaven\u00edm, ned\u00e1 sa jednoducho spravi\u0165 to, \u017ee sa vyhl\u00e1si de\u0148 a hodina, ke\u010f sa v\u0161etci prepn\u00fa na vy\u0161\u0161iu verziu IP protokolu. Okrem opera\u010dn\u00fdch syst\u00e9mov koncov\u00fdch zariaden\u00ed musia by\u0165 na prechod postupne pripraven\u00e9 aj v\u0161etky sie\u0165ov\u00e9 aplik\u00e1cie a v\u0161etky routre. Tie\u017e je potrebn\u00e9 vykona\u0165 pr\u00edslu\u0161n\u00e9 zmeny aj na DNS serveroch. Je teda nutn\u00e9 rie\u0161i\u0165 to, aby bolo s\u00fa\u010dasne mo\u017en\u00e9 fungova\u0165 nad oboma protokolmi.<\/p>\n<p>Najpravdepodobnej\u0161\u00ed scen\u00e1r je, \u017ee v\u0161etky zariadenia postupne prejd\u00fa na tzv.\u00a0<strong>dual-stack<\/strong>, \u010do znamen\u00e1, \u017ee bud\u00fa vedie\u0165 komunikova\u0165 protokolom IPv4 aj IPv6 a bud\u00fa ma\u0165 aj obe IP adresy, alebo namiesto IPv4 adresy nejak\u00fa \u0161peci\u00e1lnu IPv6 adresu, v ktorej je IPv4 adresa zakomponovan\u00e1. Ke\u010f u\u017e nastane tak\u00fdto stav, postupne bude mo\u017en\u00e9 IPv4 adresy presta\u0165 pou\u017e\u00edva\u0165 a \u010dasom u\u017e bud\u00fa v\u0161etky zariadenia komunikova\u0165 v\u00fdhradne cez IPv6. Ale to je asi e\u0161te dos\u0165 vzdialen\u00e1 bud\u00facnos\u0165.<\/p>\n<p>Zav\u00e1dza\u0165 siete s IPv6 adresami v s\u00fa\u010dasnosti je nutn\u00e9 tak, aby bolo mo\u017en\u00e9 komunikova\u0165 so zariadeniami, ktor\u00e9 maj\u00fa iba IPv4 adresy. Aj keby sme chceli komunikova\u0165 len s IPv6 sie\u0165ami, pravdepodobne sa nevyhneme tomu, \u017ee na ceste do cie\u013eovej siete p\u00f4jdu na\u0161e IPv6 datagramy cez tak\u00e9 routre, ktor\u00e9 na z\u00e1klade IPv6 adresy nevedia smerova\u0165 a rozumej\u00fa iba IPv4 adres\u00e1m v IPv4 hlavi\u010dk\u00e1ch.<\/p>\n<p>Ak chceme komunikova\u0165 z IPv6 siete do IPv4 siete m\u00f4\u017eeme pou\u017ei\u0165 niektor\u00fd z prekladov\u00fdch mechanizmov. Medzi menej \u00faspe\u0161n\u00e9 patr\u00ed\u00a0<a href=\"http:\/\/www.ietf.org\/rfc\/rfc2765.txt\">SIIT<\/a>, v ktorom sa reprezentuj\u00fa IPv4 adresy v IPv6 adres\u00e1ch v tvare \u201e::FFFF:IPv4 adresa\u201c, ktor\u00e1 sa na routri na pomedz\u00ed IPv6 a IPv4 siet\u00ed transformuje na \u201eIPv4 adresu\u201c. Probl\u00e9m tohto rie\u0161enia je, na ak\u00fa cie\u013eov\u00fa IPv4 adresu je potrebn\u00e9 zasla\u0165 odpove\u010f. \u00daspe\u0161nej\u0161\u00edm je stavov\u00fd prekladov\u00fd mechanizmus nazvan\u00fd NAT64+DNS64. Tento preklad je podobn\u00fd NAT-u z IPv4 s t\u00fdm rozdielom, \u017ee preklad sa deje iba vo\u010di IPv4 cie\u013eov\u00fdm adres\u00e1m. Postup je nasledovn\u00fd: Ak sa po\u010d\u00edta\u010d, ktor\u00fd m\u00e1 iba IPv6 adresu, sp\u00fdta v DNS64 na AAAA z\u00e1znam cie\u013eovej stanice a t\u00e1to stanica m\u00e1 iba A z\u00e1znam, DNS64 vygeneruje IPv6 adresu v tvare \u201eprefix64::IPv4adresa\u201c. Ke\u010f stanica po\u0161le tak\u00fdto datagram, odchyt\u00ed ho NAT64 router, ktor\u00fd sprav\u00ed preklad cie\u013eovej IPv6 na IPv4, a zmen\u00ed aj zdrojov\u00fa IPv6 adresu na svoju IPv4 adresu a nov\u00fd zdrojov\u00fd port a odo\u0161le tak\u00fdto IPv4 datagram do IPv4 infra\u0161trukt\u00fary. Pri pr\u00edchode odpovede sprav\u00ed opa\u010dn\u00fd preklad.<\/p>\n<p>Na vyrie\u0161enie komunik\u00e1cie medzi dvoma ostrovmi IPv6 infra\u0161trukt\u00fary cez IPv4 \u010dasti internetu sa v s\u00fa\u010dasnosti vyu\u017e\u00edvaj\u00fa r\u00f4zne tunelovacie techniky zalo\u017een\u00e9 na tom, \u017ee cel\u00fd IPv6 datagram sa na jednom mieste zabal\u00ed do IPv4 datagramu, ten cestuje be\u017en\u00fdm sp\u00f4sobom IPv4 infra\u0161trukt\u00farou a\u017e k nejak\u00e9mu zariadeniu, ktor\u00e9 rozbal\u00ed IPv4 datagram, a IPv6 datagram v \u0148om po\u0161le \u010falej k cie\u013eu u\u017e IPv6 infra\u0161trukt\u00farou.<\/p>\n<p>T\u00fdchto tunelovac\u00edch techn\u00edk existuje nieko\u013eko. Niektor\u00e9 sa pou\u017e\u00edvaj\u00fa viac, niektor\u00e9 iba ve\u013emi okrajovo.<\/p>\n<p>Celkom \u00faspe\u0161n\u00fd je sp\u00f4sob tunelovania konfigurovan\u00fdmi tunelmi, pri ktor\u00fdch si je potrebn\u00e9 ru\u010dne nastavi\u0165 tunel od svojho prekladov\u00e9ho 6na4 routra k cie\u013eov\u00e9mu prekladov\u00e9mu 4na6 routru. Existuje aj nieko\u013eko automatizovan\u00fdch mechanizmov na vyh\u013ead\u00e1vanie vhodn\u00e9ho cie\u013eov\u00e9ho prekladov\u00e9ho 4na6 routra.<\/p>\n<p>Jeden z naj\u00faspe\u0161nej\u0161\u00edch tunelovac\u00edch mechanizmov, ktor\u00fd sa ozna\u010duje\u00a0<strong>6to4<\/strong>\u00a0(<a href=\"http:\/\/www.ietf.org\/rfc\/rfc3056.txt\">RFC 3056<\/a>), rob\u00ed automatick\u00fd preklad IPv6 adries na IPv4 adresy podobne ako SIIT. Zvl\u00e1da to bezstavovo, t.j. nemus\u00ed si pam\u00e4ta\u0165 preklady, ktor\u00e9 realizoval v minulosti. Idea tohto pr\u00edstupu sa zaklad\u00e1 na tom, \u017ee prij\u00edmaj\u00faca organiz\u00e1cia m\u00e1 aspo\u0148 jednu IPv4 adresu, od ktorej sa odvodia \u0161peci\u00e1lne IPv6 adresy s prefixom 2002:IPv4 adresa:\/48 pre v\u0161etky stanice vo v\u0161etk\u00fdch podsie\u0165ach organiz\u00e1cie (okrem toho m\u00f4\u017ee ma\u0165 aj norm\u00e1lne nat\u00edvne glob\u00e1lne IPv6 adresy napr\u00edklad s prefixom 2001::\/8). IPv6 datagram s cie\u013eovou IPv6 adresou 2002:IPv4 adresa:\/48 je na 6to4 routri zabalen\u00fd do IPv4 datagramu s vyextrahovanou IPv4 adresou, ten putuje po IPv4 infra\u0161trukt\u00fare a\u017e cie\u013eovej IPv4 adrese 6to4 routra cie\u013eovej organiz\u00e1cie kde je automaticky rozbalen\u00fd a v \u0148om dopraven\u00fd IPv6 datagram je zaslan\u00fd do vn\u00fatornej siete organiz\u00e1cie a\u017e k cie\u013eov\u00e9mu zariadeniu na z\u00e1klade IPv6 adresy s prefixom 2002:IPv4 adresa:\/48.<\/p>\n<p>Trochu zlo\u017eit\u00e1 situ\u00e1cia v 6to4 je, ke\u010f zariadenie m\u00e1 iba IPv6 adresu s prefixom 2002::\/16 a nem\u00e1 nat\u00edvnu glob\u00e1lnu IPv6 adresu (napr. s prefixom 2001::\/16) a chce adresova\u0165 cie\u013eov\u00e9 zariadenie, ktor\u00e9 m\u00e1 len nat\u00edvnu glob\u00e1lnu IPv6 adresu a nem\u00e1 IPv6 adresu s prefixom 2002::\/16. V takom pr\u00edpade pri odchode cez jej hlavn\u00fd router organiz\u00e1cie nie je mo\u017en\u00e9 zabali\u0165 tak\u00fdto datagram do IPv4 datagramu s IPv4 adresou cie\u013eovej organiz\u00e1cie, ke\u010f\u017ee cie\u013eov\u00e1 organiz\u00e1cia tak\u00fa IPv4 adresu nem\u00e1.\u00a0<a href=\"http:\/\/www.ietf.org\/rfc\/rfc3068.txt\">RFC 3068<\/a>\u00a0to vyrie\u0161ilo tak, \u017ee definovalo anycastov\u00fa IPv4 adresu 192.88.99.1, na ktor\u00fa to treba posla\u0165, a ktor\u00fa odchyt\u00ed najbli\u017e\u0161\u00ed 6to4 router s glob\u00e1lnou nat\u00edvnou IPv6 adresou a uskuto\u010dn\u00ed rozbalenie a zaslanie p\u00f4vodn\u00e9ho datagramu IPv6 infra\u0161trukt\u00farou k cie\u013eu.<\/p>\n<p>Cel\u00e1 idea prechodu z IPv4 na IPv6 je pop\u00edsan\u00e1 v\u00a0<a href=\"http:\/\/www.ietf.org\/rfc\/rfc4038.txt\">RFC 4038<\/a>.<\/p>\n<p>Na \u010fal\u0161ie hlb\u0161ie \u010d\u00edtanie o IPv6 m\u00f4\u017ee v\u00fdborne posl\u00fa\u017ei\u0165 vo\u013ene stiahnute\u013en\u00e1 kniha Pavla Satrapu\u00a0<a href=\"http:\/\/knihy.nic.cz\/\">IPv6<\/a>\u00a0a tie\u017e skvel\u00fd seri\u00e1l na serveri lupa.cz\u00a0<a href=\"http:\/\/www.lupa.cz\/serialy\/pohneme-s-ipv6\/\">Pohn\u011bme s IPv6<\/a>. Pre hlb\u0161iu anal\u00fdzu bezpe\u010dnosti a nasadenia IPv6 ur\u010den\u00fa pre spr\u00e1vcov siet\u00ed vznikol seri\u00e1l\u00a0<a href=\"http:\/\/www.root.cz\/serialy\/bezpecne-ipv6\/\">Bezpe\u010dn\u00e9 IPv6.<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>IPv6: internet protocol, version 6,\u00a0RFC 2460 Protokol IPv4 sa postupne nahr\u00e1dza protokolom IPv6. Hlavnou zmenou je dlh\u0161ia IP adresa, ktor\u00e1 u\u017e nezaber\u00e1 32, ale a\u017e&hellip;<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[9],"tags":[],"_links":{"self":[{"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/posts\/337"}],"collection":[{"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/comments?post=337"}],"version-history":[{"count":4,"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/posts\/337\/revisions"}],"predecessor-version":[{"id":532,"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/posts\/337\/revisions\/532"}],"wp:attachment":[{"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/media?parent=337"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/categories?post=337"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/tags?post=337"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}