Komunikační sítě I pro integrovanou výuku VUT a VŠB-TUO

Transkript

VYSOKÁ ŠKOLA BÁŇSKÁ–TECHNICKÁ UNIVERZITA OSTRAVA
Fakulta elektrotechniky a informatiky
Komunikační sítě I pro integrovanou
výuku VUT a VŠB-TUO
Garant předmětu:
Jaroslav Zdrálek
Autor textu:
Jaroslav Zdrálek
Ostrava 2014
Vznik těchto skript byl podpořen projektem č. CZ.1.07/2.2.00/28.0062
Evropského sociálního fondu a státním rozpočtem České republiky.
Za odbornou náplň tohoto vydání odpovídá autor. Jaroslav Zdrálek je docentem na Fakultě elektrotechniky a
informatiky VŠB-Technické univerzity v Ostravě, kde přednáší předmět „Praktikum komunikačních sítí I“ pro
studenty navazujícího bakalářského studia, který součástí studijního programu Informační a komunikační
technologie.
Vznik skript byl podpořen projektem č. CZ.1.07/2.2.00/28.0062 Evropského sociálního fondu a státním rozpočtem České republiky.
Tato publikace neprošla redakční ani jazykovou úpravou.
© Jaroslav Zdrálek, 2014, VŠB-Technická univerzita Ostrava
Autor:
Jaroslav Zdrálek
Katedra:
Katedra telekomunikační techniky
Název:
Komunikační sítě I pro integrovanou výuku VUT a VŠB-TUO
Místo, rok, vydání:
Ostrava, 2014, 1. vydání
Počet stran:
85
Vydala:
Vysoká škola báňská-Technická univerzita Ostrava
Náklad
CD-ROM, 10 ks
Neprodejné
ISBN 978-80-248-3650-8
CD
Obsah
1
2
3
Úvod ................................................................................................................................. 1
1.1
Kdy dojdou IPv4 adresy ............................................................................................ 3
1.2
Reference ................................................................................................................. 4
Adresa IP verze 6 .............................................................................................................. 7
2.1
Kanonická forma IPv6 adres ..................................................................................... 7
2.2
Agregace adres ......................................................................................................... 9
2.3
IP adresy verze 6..................................................................................................... 10
2.4
Unicast adresy ........................................................................................................ 11
2.4.1
Identifikátor rozhraní ..................................................................................... 12
2.4.2
Vyhrazené unikátní adresy ............................................................................. 16
2.4.3
Lokální linková adresa .................................................................................... 17
2.4.4
Globální unicast adresa .................................................................................. 17
2.4.5
IPv4 kompatibilní adresa s IPv6 - odmítnutá .................................................. 18
2.4.6
IPv4 mapovaná adresa ................................................................................... 18
2.4.7
Místní lokální unikátní adresa - odmítnutá .................................................... 19
2.4.8
Unikátní lokální adresa ................................................................................... 19
2.5
Anycast adresy........................................................................................................ 20
2.6
Multicast adresy ..................................................................................................... 21
2.6.1
Před-definované skupinové adresy ................................................................ 24
2.6.2
Skupinové adresy vycházející z unicast adres................................................. 25
2.6.3
Skupinové adresy vycházející z rozhraní. ....................................................... 27
2.6.4
Skupinové adresy s rendezvous point ............................................................ 28
2.7
Požadované adresy uzlu ......................................................................................... 28
2.8
Dosah adres ............................................................................................................ 30
2.9
Zóna ........................................................................................................................ 32
2.10
Reference ............................................................................................................... 35
Auto-konfigurace ............................................................................................................ 39
3.1
Zeroconf pro IP adresu ........................................................................................... 40
iii
4
3.2
Auto-konfigurace IPv4 adres .................................................................................. 41
3.3
Adresy uzlu ............................................................................................................. 41
3.4
Dosah adres ............................................................................................................ 42
3.5
Auto-konfigurace IPv6 adres .................................................................................. 44
3.6
Reference ............................................................................................................... 45
Quagga............................................................................................................................ 47
4.1
Popis a konfigurace open source projektu Quagga................................................ 47
4.2
Směrovací tabulka .................................................................................................. 48
4.3
Statické směrování ................................................................................................. 49
4.3.1
Konfigurace a testování statického směrování IPv4 pomocí Quagga ............ 49
4.3.2
Konfigurace a testování statického směrování IPv4 pomocí Cisco CLI........... 51
4.3.3
Statické směrování pro IPv6 ........................................................................... 51
4.4
4.4.1
Konfigurace a testování dynamického směrování OSPF pro IPv4 .................. 54
4.4.2
Konfigurace a testování dynamického směrování OSPF pro IPv6 .................. 55
4.5
5
6
Dynamické směrování pomocí protokolu OSPF ..................................................... 53
Reference ............................................................................................................... 57
Jména a sítě .................................................................................................................... 59
5.1
Linux a jména.......................................................................................................... 60
5.2
Windows a jména ................................................................................................... 62
5.3
Prostor doménových jmen ..................................................................................... 63
5.4
Prostor doménových jmen v DNS........................................................................... 64
5.5
Domény pro speciální použití ................................................................................. 67
5.6
Generické TLD......................................................................................................... 68
5.7
Geografické TLD domény ....................................................................................... 69
5.8
TLD domény podle států ........................................................................................ 69
5.9
Infrastrukturní doména arpa .................................................................................. 70
5.10
Internacionalizace doménových jmen ................................................................... 71
5.11
Punycode ................................................................................................................ 73
5.12
Reference ............................................................................................................... 74
Unicode .......................................................................................................................... 77
6.1
Použití Unicode....................................................................................................... 80
6.2
UTF-32 .................................................................................................................... 80
6.3
UTF-16 .................................................................................................................... 80
6.4
UTF-8 ...................................................................................................................... 82
iv
6.5
ASCII kód................................................................................................................. 84
6.6
Reference ............................................................................................................... 84
v
Komunikační systémy I pro integrovanou výuku VUT a VŠB-TUO
1 Úvod
Internet protokol je jedním ze základních protokolů Internetu. Původní verze protokolu 4
vznikla v 70 letech minulého století a byla publikována v září 1981 jako RFC 791. Od této
doby došlo k širokému rozšíření používání a protokol byl postupně doplňován o další vlastnosti, jako je šifrování, přechod od tříd IP adres k agregaci IP adres, vytváření virtuálních sítí
a další.
Skupina odborníku se již začátkem 90 let zamyslela nad jeho budoucnosti a navrhla novou
verzi protokolu, do které byly zapracovány nové poznatky a požadavky [Satrapa_2011]:










zvýšení bezpečnosti (zahrnout do IPv6 mechanismy pro šifrování, autentizaci a sledování cesty k odesilateli)
podpora pro služby se zajištěnou kvalitou
optimalizace pro vysokorychlostní směrování
automatická konfigurace (pokud možno plug and play)
podpora mobility (přenosné počítače apod.)
rozsáhlý adresní prostor, který vystačí pokud možno navždy
tři druhy adres: unicast, skupinové (multicast) a výběrové (anycast)
jednotné adresní schéma pro Internet i vnitřní sítě
hierarchické směrování v souladu s hierarchickou adresací
hladký a plynulý přechod z IPv4 na IPv6
Výsledkem prací byl nový Internetový protokol 6, který byl publikován v prosinci 1995 jako
RFC 1883. Nový protokol byl volen tak, aby byly minimální nebo vůbec žádné změny
v ostatních protokolech Internetu. V porovnání s protokolem IP verze 4 nový protokol
přináší:



Beze-stavovou automatickou konfiguraci IP adres. Jedná se o situaci, kdy uzel sítě
se konfiguruje bez potřeby DHCP serveru. Jsou definované algoritmy, které umožňují uzlu získat a nastavit základní informace potřebné k přenosu paketů.
Multicasting. Jedná se o situaci, kdy paket je přenášen z jednoho zdroje do více cílových uzlů. Tato vlastnost je součástí IPv4, ale IPv6 ji vylepšuje na základě získaných poznatků z provozu na IPv6.
Broadcasting. Jedná se o všesměrovou adresu v protokolu IPv4, kdy příjemcem jsou
všechny uzly. Protokol IPv6 broadcasting ruší a nahrazuje jej multicast adresou
s dosahem. Multicast adresa definuje, které typy uzlů se oslovují, a dosah určuje
část sítě, ve které se tyto uzly oslovují.
1
Automatická
konfigurace□
Multicasting□
Broadcasting□







Bezpečnost na úrovni síťové vrstvy. Jedná se definici protokolu IPsec, spolu s novým
protokolem IPv6. Pro aplikaci v protokolu IPv4 byl bezpečností protokol IPsec dodatečně modifikován.
Zjednodušení zpracování paketů v routrech. I když základní hlavička IPv6 (40 bytů)
je dvakrát větší než u protokolu IPv4 (20 bytů), zpracování paketů v routrech je
efektivnější, rychlejší. Zároveň se tímto rozšiřuje end-to-end princip v Internetu.
Zjednodušení lze spatřovat:
 Hlavička IPv6 je jednodušší než hlavička IPv4, která obsahuje zřídka používané pole. V případě IPv6 byly toto doplňující pole přeneseny do rozšiřujících hlaviček.
 Směrovače IPv6 nevykonávají fragmentaci. Protokol IPv6 definuje MTU na
1 280 bytů. V případě, že IPv6 host má zájem použít jinou velikost MTU, potom si musí sám zajistit vyhledání vhodné cesty a fragmentaci.
 Hlavička IPv6 není chráněna kontrolním součtem jako u IPv4. Detekce a
oprava chyb je přenesena na sousední vrstvy modelu, nižší a vyšší úroveň,
linkovou a TCP, UDP úroveň. V důsledku toho nemusí směrovače přepočítávat kontrolní součet, pokud změní hodnotu pole hop limit. Tímto se snižuje
výpočetní zátěž směrovačů. Dalším důsledkem je, že UDP protokol pro IPv6
musel být doplněn o kontrolní součet. Původní UDP protokol pro IPv4 totiž
kontrolní součet neměl.
 Pole TTL, Time to Live, hlavičky IPv4 bylo přejmenováno na pojem Hop Limit. Tato skutečnost napravuje situaci, kdy směrovače již neměří čas, který
paket strávil v řadě, ale že pole vyjadřuje počet zbývajících hopů.
 Zmenšení směrovacích tabulek v páteřních směrovačích Internetu
v porovnání s protokolem IPv4. IPv6 adresy mají hierarchické geografické
uspořádání.
Mobilita. Jedná se aplikaci mobilních zařízení v Internetu a zabránění trojúhelníkovému směrování. Do IPv6 mobilita je zapracována od začátku, do IPv4 byla zapracována dodatečně.
Rozšiřitelnost hlavičky. Základní hlavička protokolu IPv6 má 40 bytů a lze ji rozšiřovat o další volitelné volby, Next Header. Některé volbu jsou již dnes definovány a
v budoucnosti se očekávají nové volby související mobilitou, bezpečností a dalšími
vlastnosti.
Jumbograms. Jedná se o zvětšení velikosti paketu. Velikost paketu IPv4 je maximálně 65 535 bytů (216-1). Protokol IPv6 má však dvě, základní velikost s maximálním
počtem 65 535 bytů a volitelnou možnost velikosti paketu až do velikosti (232-1)
4 294 967 295 bytů. Tento paket je označován jako jumbogram a je definován rozšiřující hlavičkou.
Soukromí. IP adresy jsou globální a jedinečné, tím pádem lze je sledovat. Protokol
IPv6 umožňuje nahrazovat MAC adresu náhodně generovanou adresou, která je zároveň časově omezena. Tímto opatřením se zvyšuje ochrana soukromí uživatelů Internetu. Odstranění NAT tabulek je také jedním s opatření na zvýšení soukromí.
Dostatečný adresný prostor. 128 bitů IPv6 adresy zajišťuje dostatečná rozsáhlý adresný prostor, který umožňuje hierarchické členění IP adresy a poskytuje prostor do
2
IPsec□
Routry - jednodušší, rychlejší□
Hierarchické
geografické
uspořádání IPv6
adres□
Mobilita□
Next Header□
Jumbogram□
Soukromí□
128 bitové IP
adresy□
budoucnosti. Předpokládá se odstranění NAT tabulek. Problémy, které vznikly
s IPv4 adresami se neočekávají.
Poznámka k end-to-end principu
Základní myšlenka end-to-end- principu je, že v sítích pro všeobecné použití, funkce spojované s aplikací by měly být umístěny na koncových bodech sítě (end hosts) nikoliv na
interních bodech sítě, [wiki_0102]. Příkladem může být zajištění spolehlivosti přenosu
koncovými uzly sítě namísto interních uzlů sítě, jako jsou přepínače nebo směrovače
(switches or routers). Přenesení na koncové body je levnější a zároveň univerzální řešení.□
Internet protokol verze 6 byl prvn2 definován v roce 1995 a je stále doplňován o upřesňující
informace. Proto ve světě Internetu vznikly laboratoře, které certifikují problematiku IP
IPv6 Forum□
verze 6. Jedna z významných certifikačních autorit je IPv6 Forum, [Internet_0102], kde
čestným předsedou je Vint Cerf. IPv6 Forum sdružuje několik laboratoří rozprostřených po
celém světě a uděluje certifikační loga IPv6, obr. 01-01. Jak je vidět z obrázku, jednotlivé
loga jsou specializovány na určitou problematiku IPv6.
Obr. 01-01 Certifikační loga IPv6 Forum
Poznámka k počtu adres
Celkový počet IPv6 je 2128 = 3,40 * 1038 adres. Pro představu, při počtu obyvatel Země 7
miliard, připadá na každého jedince 4,86 * 1028 adres a na jeden 1 m čtvereční Země připadá 6,67 * 1023 adres.□
1.1 Kdy dojdou IPv4 adresy
Ve světě jsou různé názory, kdy dojde k vyčerpání IPv4 veřejných adres. I když protokol IPv6
byl navrhován tak, aby umožnil snadný přechod s IPv4 na IPv6, je opak pravdou. Hodně
poskytovatelů Internetu se drží protokolu IPv4 a nedostatek IPv4 adres řeší formou překladu adres a využíváním neveřejných IPv4 adres, aplikace NAT – Network Translation Table.
3
RIR
APNIC
RIPE NCC
LACNIC
ARIN
AFRINIC
Datum, kdy byl uvolZbývající
něn poslední pool adresy v pool /8
14. duben 2011
0,7932
14. září 2012
0,9686
10. červen 2014
0,2094
0,5635
2,9203
Región
Asie a Pacifik
Evropa, Střední východ, centrální Asie
Latinská Amerika a Karibské ostrovy
Severní Amerika
Afrika
Zdroj: http://www.potaroo.net/tools/ipv4/
Obr. 01-02 Tabulka volných IPv4 adres u regionálních distributorů
AFRINIC
APNIC
ARIN
RIPENCC
LACNIC
Zdroj: http://www.potaroo.net/tools/ipv4/
Obr. 01-03 Stav zbývajících IPv4 adres, listopad 2014
IANA, jako nejvyšší autorita internetu, ke dni 3. února 2011 uvolnila všechny zbývající volné
veřejné adresy regionálním administrátorům RIR. V současnosti IANA již nemá volné IPv4
adresy. Stav volných IPv4 adres u RIR administrátorů a tendence do budoucnosti je na
obr. 01-02. Nejhůře na tom je región latinské Ameriky (LACNIC) následovaný severní Amerikou (ARIN). Prvotní odhady, že nejhůře na tom bude región Asie a Tichomoří (APNIC) se
nenaplnily a počet IPv4 adres klesá pozvolna.
Počet zbývajících IPv4 adres se měří v poolu o velikosti 8 bitů. Jedná se o první číslici IPv4
adresy. Celkově je 256 poolů a každý pool obsahuje 224 adres, 16 Mi adres. V tabulce a grafu
je uvedena volná velikost poolu, ve kterém jsou volné nepřiřazené veřejné IPv4 adresy,
[Internet_0101], [wiki_0103]. Uvedené datum značí, že RIR uvolnil poslední /8 pool a dostal
se do kritické situace. Od tohoto data již RIR přiřazuje pool o maximální velikosti /22, tj. blok
o 1 024 adresách.
1.2 Reference
[Internet_0101]IPv4 Address Report; http://www.potaroo.net/tools/ipv4/; on line 2014-1128
[Internet_0102]IPv6 Forum; http://www.ipv6forum.com/; on line 2014-11-28
4
[Satrapa_2011] Pavel Satrapa: Internetový protokol verze 6; cz.nic 2011; ISBN 978-80904248-4-5; http://knihy.nic.cz/files/nic/edice/pavel_satrapa_
ipv6_2012.pdf; on line 2014-11-20
[wiki_0101]
IPv4 address exhaustion;
http://en.wikipedia.org/wiki/IPv4_address_exhaustion; on line 2014-11-01
5
2 Adresa IP verze 6
Předpokládá se, že budoucí Internet bude používat Internet protokol verze 6. V současnosti
však ještě převládá jeho verze 4. Seznámit se Internet protokolem verze 6 je možné buď
studiem samotného komunikačního protokolu, nebo aspoň adresní architekturou. Studium
komunikačního Internet protokolu verze 6 značí se zabývat formátem paketu, definicí polí
v paketu. Zde je zvolen trochu jiný způsob, který může vést k pochopení Internet protokolu
z pohledu studia adresní architektury Internet protokolu verze 6.
2.1 Kanonická forma IPv6 adres
Adresa IP protokolu verze 6 byla prvně definována v roce 1995, dnes je platné RFC 4291
z roku 2006. IP adresa verze 6 je dlouhá 128 bitů a zapisuje do 8 skupin oddělených dvojtečkou, potom každá skupina obsahuje 16 bitů. Každá skupina se zapisuje pomocí hexadecimální soustavy. Preferovaná forma zápisu podle RFC4291 je
1234:5678:90AB:CDEF:1234:5678:90AB:CDEF
2001:DB8:0:0:8:800:200C:417A
Preferovaná
V zápisu se mohou vyskytovat nuly, které umožňují zápis zkrátit. Pokud skupina má na forma podle
□
nejvýznamnějších pozicích nuly, potom se tyto vynechávají. Skupina obsahující čtyři hexa- RFC4291
decimální nuly se zkracuje na jednu nulu.
RFC 4291 dovoluje další zkracování zápisu vynecháním po sobě jdoucích skupin s hodnotou
nula. K tomuto zkrácení se používají dvě dvojtečky „::“.
2001:DB8:0:0:8:800:200C:417A

2001:DB8::8:800:200C:417A
2001:0:0:0:8:0:0:11

2001::8:0:0:11
2001:0:0:0:8:0:0:11

2001:0:0:0:8::11
FF01:0:0:0:0:0:0:101

FF01::101
0:0:0:0:0:FFFF.158.196.149.111

::FFFF.158.196.149.111
Zkrácení pomocí
„::“□
Aplikace dvou dvojteček v zápisu může být pouze jeden krát a na libovolném místě. Dvě
dvojtečky „::“ nahrazují libovolný počet nulových skupin. Je možný i zápis IP adresy jako ::, a
tento zápis odpovídá nulové IP adrese s významem nedefinovaná.
RFC 4291 nespecifikuje způsob zápisu hexadecimálních číslic, které odpovídají písmenům.
Mohou se psát malými či velkými písmeny. RFC 4291 používá velké písmena. Pokud IP
adresa obsahuje dvě sekvence nulových skupin, potom RFC 4291 nespecifikuje, na kterou
se má aplikovat zkrácení pomocí dvou dvojteček.
7
IP adresa verze je dlouhá a předpokládá se, že běžní uživatelé budou používat DNS systém,
který nahradí ID adresu jmény. Naopak správci sítě se ji naučí používat. Správců je menšina.
Více možných zápisů IP adresy verze 6 může vést k mnoha nesrovnalostem. Například:



možná záměna hexadecimální hodnot D a 0, nebo B a 8.
Problémy při vyhledávání adresy a to aplikací malých a velkých písmen pro hexadecimální hodnoty v zápisu a aplikace principu zkracování, které lze použít na libovolnou sekvenci.
Mnozí uživatele si budou mít problém uvědomit, že IP adresy 2001:DB8::417A a
2001:0DB8:0:0:0:0:0:417A jsou totožné. Toto platí i pro vyhledávací programy.
Z důvodu nejednoznačnosti zápisu IP adresy verze 6 byla definována kanonická forma
textového zobrazení IP adresy verze 6, RFC 5952, rok 2010. Očekává se, že kanonická forma Kanonická forma
zobrazení je vhodná pro lidi a systémy, které zobrazují IP adresu verze 6 jako text. Naproti zápisu IP adresy
tomu zápis IP adresy verze 6 v interních paměťových zařízeních, aplikacích nebo databázích verze 6□
musí splňovat RFC 4291 a není vázán kanonickou formou. Z Následujících možných zápisů IP
adresy verze 6 podle RFC 4291 je pouze poslední zápis v kanonické formě podle RFC 5952.
V dalším textu se budeme zabývat pouze touto formou.
20aa:0001:0000:2345:0000:0000:0000:0CDE
20AA:001:000:2345:00:00:0:CdE
20aA:01:0:2345:0:0:0:cde
20aa:1::2345:0:0:0:cde
20aa:1:0:2345::9abc
// kanonická forma
Aplikace kanonické formy je v souladu s původním RFC 4291. Jednotlivá doporučení pro
textové zobrazení IP adresy verze 6 jsou:


Práce s vedoucími nulami v 16 bitové skupině. Nuly na nejvíce významových poziNuly ve skupině□
cích ve skupině musí být potlačeny. Například zápis IP adresy ve tvaru
2001:00b8::0001 je v kanonické formě nepřípustný a musí být nahrazen zápisem
2001:b8::1, kanonická forma. Pokud IP adresa obsahuje skupinu čtyř hexadecimálních nul, 0000, potom tato skupina musí být nahrazena jednou nulou, 0.
Pravidla aplikace zkrácení IP adresy použitím dvou dvojteček „::“.
 Co největší zkrácení. Použití symbolu „::“ musí být v co největší míře.
Co největší
zkrácení pomocí
2001:b8:0:0:0:0:0:1

2001:b8::1
„::“□
Zápisy 2001:b8:::0:1 nebo 2001:b8::0:0:1 a podobně neodpovídají kanonické formě.
 Jedna skupina s hodnotou 0. Tato skupina nesmí být nahrazena znakem
„::“. Například IP adresa 2001:b8:c9:d0:e1:f2:0:1 nesmí být zkrácena na
2001:b8:c9:d0:e1:f2::1. První zápis je kanonická forma.
 Umístění zkrácení „::“. IP adresa verze 6 může obsahovat více polí s nuloZkracovat nejdelvými skupinami, například 2001:0:0:cde:0:0:0:1. Potom pro tvorbu kanonicší sekvenci skuké formy platí, že pole s delší sekvencí skupin s nulovou hodnotou musí být
pin□
8
zkráceno aplikací „::“. Pokud obě pole mají stejnou délku sekvence skupin
s nulovou hodnotou, potom musí být zkrácena první sekvence.
2001:0:0:cde:0:0:0:1

2001:0:0:cde::1
2001:0:0:b8:cde:0:0:1

2001::b8:cde:0:0:1
Aplikovat malé
písmena na
 Malá písmena. Hexadecimální hodnoty odpovídající písmenům musí být psána
hexadecimální
malými písmeny, a to „a“, „b“, „c“, „d“, „e“, a „f“.
hodnoty□
Protokol IP verze 6 je nástupcem IP protokolu IP verze 4 a proto definuje zápis IP adres
verze 4 ve formátu verze 6. Následný zápis je kanonický zápis, úvodní sekvence nulových
Zápis IPv4 adresy
skupin je zkrácena.
ve formátu IPv6□
::ffff:123.145.167.189
S použitím IP adresy v TCP protokolu souvisí pojem port. Spojením IP adresy a portu vzniká
soket. Možné zápisy soketů podle RFC 5952 jsou:






[2001:db8::1]:80
2001:db8::1:80
2001:db8::1.80
2001:db8::1 port 80
2001:db8::1p80
2001:db8::1#80
// defaultní zápis, URI zápis podle RFC 3986
// nedoporučený zápis
Zápis soketu□
RFC 5952 doporučuje používat první zápis s hranatými uvozovkami „[]“ pokud jiné platné
RFC nedefinuje jiný způsob zápisu. Zápis ve stylu „[]“ je také podporován RFC 3986, které
pojednává o zápisu URI - Uniform Resource Identifier s IP adresou verze 6. Zápis podle
druhé odrážky se nedoporučuje používat, protože přináší nejednoznačnost, protože hodnotu 80 lze chápat jako poslední skupinu IP adresu nebo jako port. Port 80 je port http protokolu a souvisí s weby.
2.2 Agregace adres
Agregace adres je způsob alokace IPv6 adres, který napomáhá směrování Internetu. Základ- Agregace adres□
ní myšlenka agregace adres, že nejvíce významové bity určují rozsáhlejší část Internetu. Dá
se také říci, že významnější bity určují adresu sítě a další následující adresu podsítě. Tento
princip lze také chápat jako základ hierarchického směrování. Výhodným důsledkem agregace adres snížení kapacitních nároků na směrovací tabulky směrovačů a tím zrychlení
směrování. Tento princip je znám z IP protokolu verze 4, kde je označován, jako CIDR Classless Inter-Domain Routing, RFC 4632.
S pojmem agregace adres se váže pojem prefix, který právě udává počet bitů sítě v IP adrese verze 6. Prefix se zapisuje pomocí znaku lomítka „/“, za IP adresou, kde za lomítkem se
zapisuje počet nejvíce významových bitů. Tento počet se nazývá prefix a definuje adresu
sítě. Následující zápisy definují síťový prefix. Z pohledu kanonického zápisu IP adresy musí Prefix určuje
být prefix jednoznačný, pokud hranice leží uprostřed 16 bitové, potom skupina musí být počet bitů IP
adresy zleva jako
zapsána na 16 bitů. Jsou zde míněny nuly vpravo, obr. 02-01.
adresu sítě□
9
IPv6 adresa
1abc:0:c::/48
Význam
Adresa sítě
Poznámka
Adresa sítě má 48 bitů zleva
1234:123c::/28
Adresa sítě
fe80::/10
Lokální unicast adresa
2000::/3
Globální unicast
adresa
Adresa sítě má 28 bitů zleva
Adresa sítě má 10 bitů a její jednoznačnost
je pouze na lokální lince
Adresa sítě má 3 bity a její jednoznačnost je
globální
Obr 02-01 Zápis prefixu
Prefix IP verze 6 adresy jednak určuje síť, ale se také používá k označení určité skupiny
adres, které mají vlastní formáty, způsob adresování a jednoznačnost definovanou dosahem. Potom tyto skupiny adres se definují také prefixem, který je potom povinný pro danou
skupinu adres.
2.3 IP adresy verze 6
Internet protokol verze 6 zajišťuje doručování dat mezi zdrojem a cílem pomocí paketů.
K tomu je mu nápomocná adresní architektura, která definuje základy pro jednoznačnou
identifikaci zdroje a cíle dat. Prvním účelem adresní architektury Internet protokolu verze 6
je zajistit:


Jednoznačnou identifikaci rozhraní uzlu v sítí. IP adresa se váže na síťové rozhraní
Více IPv6 adres
nikoliv k uzlu. Nutno si uvědomit, že uzel sítě může mít jedno nebo více rozhraní.
k jednomu rozPotom uzel sítě má více cíle nebo více rozhraní cílů jako uzlu sítě. Jednoznačná
hraní□
identifikace je svázaná s dosahem, který definuje rozsah sítě, kde jednoznačnost je
zajištěna. Nejznámější dosahy jsou globální a lokální.
Směrování. Směrování je proces, který zajišťuje doručení dat mezi zdrojem a cílem
pomocí paketů nebo datagramů. Směrování zajištují uzly sítě s funkcí směrovač,
které vybírají nejvhodnější cestu mezi zdrojem a cílem z více možných cest. Za tímto
účelem směrování se využívají sítě a podsítě, kterým je jednoznačně přiřazena cest.
Proto IP adresa obsahuje informace o sítích a podsítích, které slouží ke směrování.
Sítě a podsítě jsou definované jako část IP adresy pomocí prefixů.
Poslední definice adresní architektury IP protokolu vezte 6 je definována RFC 4291 z roku
2006 a následnými updaty. Další ucelené informace jsou v literatuře [Satrapa_2011],
[TCPIP_guide].
Adresní architektura protokolu IP verze 6 definuje základní způsoby adresace mezi zdrojem
a cílem, Obr. 02-02. Červený bod značí zdroj, zelený cíl nebo cíle a žlutý bod další uzly sítě.
Unicast
Základní způsoby adresace jsou unicast, anycast a multicast s významem:
Anycast
□
 Unicast addressing – unicast adresace. Jedná se o adresaci ze zdroje do jednoho cí- Multicast

le, který má jedinečnou IP adresu v definovaném rozsahu sítě, [wiki_0204].
Anycast addressing – výběrová adresace. Jedná se o adresaci ze zdroje do jednoho
z mnoha cílů. Všechny cíle mají stejnou IPv6 adresu a paket je doručen do topologicky nejbližšího cíle, [wiki_0205].
10

Multicast addressing – skupinová adresace. Jedná se o adresaci z jednoho zdroje do
mnoha cílů v definovaném rozsahu sítě a tyto cíle mají přidělenou skupinovou adresu. Paket je doručován do všech multicast cílů souběžně. Společnou část cesty je šířen v jedné kopii a v bodě rozdělení se rozdělí do jednotlivých cílů, [wiki_0206].
Unicast
Anycast
Multicast
Obr. 02-02 Způsoby adresace
Poznámka k broadcast adresaci - všesměrové adresaci
Broadcast adresace je adresace z jednoho zdroje všem cílům. Protokol IPv6 však broadcast adresaci nepoužívá a nahrazuje ji multicast adresaci a dosahem.□
Od základních způsobů adresování jsou odvozeny základní skupiny IP adres verze 6, unicast,
Dosah IPv6
výběrové a skupinové. Adresní architektura IP protokolu verze 6 definuje dosah adresy,
□
jedná se o část sítě, kde tato adresa je platná. Za základní rozsahy lze považovat globální a adres
lokální dosah, popřípadě místní dosah. Skupinové adresy mají definované více dosahů v
jemnějším členění. Globální dosah značí, že adresa je platná v celém Internetu, naproti
tomu lokální adresa je platná a šířena pouze v podsíti, která je ohraničená nejbližším portem směrovače.
2.4 Unicast adresy
Unicast adresy definují adresu cíle jako unikátní při přenosu dat. Data jsou přenášena
Unicast adresy –
z jednoho zdroje do jednoho cíle, právě s unikátní neboli jednoznačnou adresou. Unikátní
unicast addressadresa je jedinečná v definovaném dosahu v sítě a tím je zajištěna jednoznačná identifikace
es □
cíle. Některá literatura používá pojem individuální adresa.
Úroveň znalostí o adresní architektuře protokolu IPv6 v jednotlivých uzlech sítě závisí od
role uzlu v sítí. Například, některé koncové uzly sítě nemusí znát strukturu unikátní adresy
vůbec nebo jenom základní dělení na prefix a identifikátor rozhraní. Naproti tomu směrovače musí umět pracovat se podsítěmi, které jsou definované prefixy. V základě se unikátní
adresa dělí na dvě části, a to prefix podsítě a identifikátor rozhraní, obr. 02-03.
11
127
n bitů
Prefix podsítě
(128 – n) bitů
0
Identifikátor rozhraní
Obr. 02-03 Základní formát unicast adresy
Prefix podsítě je důležitá informace pro směrovače, na základě které se rozhoduje o směrování. Princip prefixů a agregace definuje hierarchické uspořádání. Směrovač potom pracuje
s jedním nebo několika prefixy. Aplikace prefixů neboli hierarchických hranic se bude lišit od
postavení směrovače v hierarchii.
Identifikátor rozhraní určuje konkrétní síťový adaptér v dané podsítí, identifikátor rozhraní
musí být jednoznačný v dané podsíti. Konkrétní způsob odvození či definice identifikátoru
rozhraní závisí od různých kritérií a způsobu použití. U některých unikátních adres se používá modifikovaný EUI-64 identifikátor, který je globálně jednoznačný. Z důvodů ochrany
soukromí se doporučuje používat dočasný identifikátor rozhraní. Naproti tomu z důvodu
bezpečnosti se používá kryptografický generovaný identifikátor. RFC 7136 tuto problematiku pro unicast adresy kromě mapovaných následovně.
Identifikátor interfejsu je dlouhý 64 bitů. Pokud je identifikátor interfejsu odvozen od MAC RFC 7136 □
adresy musí být aplikován modifikovaný EUI-64 identifikátor.
Unikátní adresy jsou vyhrazené adresy, lokální a místní unikátní adresy, globální unikátní
adresy a IPv6 adresy obsahující adresu IPv4.
Poznámka k pojmům unikátní a globální
Pojmy unikátní a globální nejsou totožné. Pojem unikátní definuje způsob adresa, to je
jeden cíl. Pojem globální definuje rozsah platnosti IP adresy, to je celý Internet. Potom
globální unikátní adresa je adresa jednoznačná v celém Internetu. IPv6 potom místo pojmu
rozsah používá pojem dosah.□
Protokol IPv4 má definované neveřejné adresy a jejich platnost je omezená na předem
definovanou síť. Neveřejné IPv4 adresy nelze použít v Internetu jako celosvětové síti. Adresní architektura IPv6 protokolu tuto myšlenku rozvíjí a definuje dosah IPv6 adresy. Dosah
adresy je vlastnost skupinových adres a je vysvětlen v jedné z následujících kapitol. Částečně je dosah aplikován i na unikátní adresy a to lokální a místní dosah.
2.4.1 Identifikátor rozhraní
S adresami IP verze 6 úzce souvisí identifikátor interfejsu. Je to nejméně významová část IP
adresy verze 6 a v mnoha případech je dlouhá 64 bitů. Identifikátor interfejsu je generován
několika způsoby, které jsou dány jednak typy IPv6 adres nebo jinými kritérií, například
ochrana soukromí, bezpečnost. Základní identifikátor interfejsu modifikovaný EUI-64 identifikátor, který se odvozuje od fyzické adresy interfejsu MAC.
12
Interfejs nebo rozhraní je vlastně adaptér, který připojuje zařízení do sítě. Každý adaptér má
přiřazený identifikátor, který je v definovaném rozsahu sítě jednoznačný. Síťový adaptér se NIC, interfejs,
□
také označuje zkratkou NIC – Network Interface Controller a identifikátor interfejsu se často rozhraní
označuje pojmem MAC adresa. Nutno si uvědomit, že host může mít více interfejsů, například server nebo směrovač.
Network host, síťový host je počítač či jiné hardwarové zařízení připojené do sítě. Host sítě
poskytuje informace, služby a aplikace uživatelům nebo ostatním uzlům v sítí, [wiki_0209]. Síťový host□
Existuje pojem Internet host, což je zařízení, které používá Protokoly Internetu a IP adresu.
Většinou se používá pouze pojem host, jako uzel sítě, který má přiřazenou jednu nebo více
IP adres. Typickým hostem je počítač, jednak ve funkci serveru tak i ve funkci klienta. Uzly
sítě, které komunikují principem peer-to-peer se také označují jako hosti. Naproti tomu
zařízení jako síťový modem, směrovač, tiskárna apod. nejsou označované za síťové hosty.
MAC adresa, Media Access Control address, je identifikátor, který přiřazený adaptéru síťového rozhraní - NIC, [wiki_0208]. Namísto MAC adresa se také používá pojem fyzická adre- MAC adresa□
sa. Další pojem spjatý s MAC adresou je EUI-48 identifikátor. Původně MAC adresa byla
spjata s Ethernetem a ne všechny typy síťových adaptérů používaly tento formát.
Dnes je tento formát dán doporučením IEEE 802 a je používán i v dalších síťových adaptérech, obr. 02-04. Podle doporučení IEE 802 má identifikátor 48 bitů a skládá ze dvou částí,
každá po 24 bitech. První část je OUI - Organizationally Unique Identifier, identifikace výrobce NIC adapteru. Druhá část je identifikátor rozhraní, který přiřazuje samotný výrobce,
obr. 02-04. Přidělování OUI kódu je spravováno registrační autoritou IEEE, čímž se zajišťuje
jedinečnost tohoto kódu.
MAC adresa se zapisuje po bytech oddělených pomlčkou „-“ nebo dvojtečkou „:“. Každý
byte je vyjádřen dvěma hexadecimálními číslicemi. Žádná nula se nevypouští a velikost
písmen, které odpovídají hexadecimálním hodnotám, není definována. MAC adresa se ve
Windows zobrazuje velkými písmeny a pro změnu v Linuxu, malými písmeny.
MSB byte MAC adresy podle IEEE 802 obsahuje dva bity, které určují její vlastnosti. První
z nich je označován jako U/L bit a má význam univerzální/lokální. Je-li U/L bit roven 0,
potom se jedná o globální MAC adresu. Pokud je U/L bit roven 1, potom se jedná o adresu,
která je spravována lokálně. Jedinečnost lokální MAC adresy je omezena na definovaný
rozsah sítě. Většinou se jedná o podsíť, která je ohraničena nejbližším portem směrovače.
Nejméně významový bit prvního bytu je označován jako I/G, obr. 02-04. Když je tento bit
roven nule, potom se jedná o globální identifikátor. V opačném případě, I/G bit je roven Unikátní globální
□
jedné, MAC adresa je multicast. Unicast adresa značí, že musí být unikátní nebo-li jedno- MAC adresa
značná v definovaném rozsahu sítě. Globální adresa je adresa platná v celém Internetu,
neznačí to, že je unikátní.
Výrobce, který přiřazuje MAC adresu síťovému adaptéru, nastavuje U/L bit roven 1 a I/G bit
□
roven 0. To značí, výrobce přiřazuje síťovému rozhraní unikátní globální adresu. Tato glo- MAC adresa
bální unikátní MAC adresa je jednoznačná v celém Internetu, je pevně spojena s adapterem
13
a nejde odstranit. Možný způsob uložení MAC adresy na adaptéru je umístění do ROM
paměti adaptéru.
OUI - Identifikace výrobce
MSB
byte
U/L I/G
Zápis
10-2A-3B-4C-5D-0E
10:2A:3B:4C:5D:0E
byte
byte
Identifikace rozhraní
byte
byte
byte
LSB
0 – Unicastová adresa
1 – Multicastová adresa
0 – Globálně unikátní identifikátor
1 – Lokálně spravovaný identifikátor
Obr. 02-04 Formát MAC adresy
MAC adresa se využívá na linkové vrstvě komunikačního modelu, kdy do linky mohou být
připojeny dva nebo více NIC adapteru. Příkladem, kdy na linku je připojeno více adaptéru je
WiFi síť nebo aplikace síťového mostu. Jedna buňka WiFi sítě se vyznačuje jedním centrálním prvkem a více uživateli a všichni sdílejí jedno přenosové medium. Síťový most se dnes
jako hardwarové zařízení nepoužívá, ale se softwarovou realizaci se lze setkat ve virtualizaci. Pokud je aplikován drátový Ethernet na úrovni linkové vrstvy, potom se používají přepínače, a na lince jsou pouze dva NIC adaptéry.
Sítový adaptér NIC potom přijímá pouze ty rámce, které jsou určeny pouze jemu. Podle IEEE
Adresace na
se jedná o unikátní adresy a další předem definované adresy.
linkové vrstvě□
 Unikátní MAC adresa. NIC adaptér porovnává svou unikátní MAC adresu s cílovou
adresou v rámci.
 Multicastové MAC adresy. NIC je členem skupiny a je využívána multicastová adresace.
 00-00-00-00-00-00, samé nuly, jedná se o adresu o neznámou MAC adresu. Neznámá adresa je použita, pokud protokol nazná adresu cíle, souseda, brány apod. Tato
adresa se používá hlavně v konfiguračních protokolech sítě. Nulová adresa nesmí
být pevně přiřazena žádnému adaptéru jako unikátní adresa.
 FF-FF-FF-FF-FF-FF, samé jedničky, jedná se o adresu broadcastu na linkové vrstvě.
V souvislosti s IP protokolem verze 6 se tato adresa nepoužívá. Broadcastová linková adresa je použita v IP protokolu verze 4, například protokolem ARP. Broadcastová adresa nesmí být pevně přiřazena žádnému adapteru jako unikátní adresa.
Poznámka k protokolu ARP
Protokol ARP, Address Resolution Protocol, se využívá k překladu dané IPv4 adresy na
odpovídající MAC adresu, RFC 826. Zjištěná MAC adresa je buď MAC adresa uzlu v rámci
podsítě, nebo je to MAC adresa brány podsítě. Reverzní překlad, MAC adresa na IP adresu
zajišťuje RARP protokol, Reverse ARP.□
14
RFC 7136□
IP adresy verze 6 se skládá s prefixu sítě a identifikátoru rozhraní. Identifikátor interfejsu je
64 bitů dlouhý. Pokud je identifikátor odvozen od fyzické adresy rozhraní MAC, potom musí
být použitý modifikovaný EUI-64 identifikátor, RFC 7136. Sestavení modifikovaného EUI-64
identifikátoru je na obr. 02-05. Modifikovaný EUI-64 identifikátor je dán RFC 4291, Appendix A, a mění význam bitu, který udává globální nebo lokální identifikátor. Modifikovaný
EUI-64 identifikátor používá označení pro tento bit označení U/L bit, univerzální/lokální bit. Modifikovaný
Hodnota nula U/L bitu značí lokální identifikátor a hodnota 1 univerzální. Způsob odvození EUI-64 identifikátor□
modifikovaného EUI-64 identifikátoru je dán algoritmem:



48 bitová MAC adresa se rozdělí na dvě skupiny po 24 bitech. MAC adresa se zapisuje jako sekvence 6 bytů v hexadecimální soustavě.
Do středu se vloží sekvence dvou bytů 0xFF a 0xFE.
Zneguje se bit, který udává globálnost či lokálnost identifikátoru.
Poznámka k termínu EUI-64
IEEE 802 definuje několik formátů identifikátoru EUI mezi nimi je EUI-64. IP adresa verze 6
však používá modifikovaný EUI-64 identifikátor, který je dán RFC 4291.
V uvedených obrázcích úmyslně není uvedeno číslování bitů, protože IEEE 802 a RFRC 4291
používají odlišné číslování bytů, bitů. Uvedené pozice bitů a zápis MAC adresy je v tomto
dokumentu uveden v takovém pořadí, jak je možné si MAC adresu přečíst v operačních
systémech. Stejné pořadí je i při sériovém přenosu.□
00-01-2A-3B-4C-5D
48 bitová MAC adresa
0000 0000 0000 0001 0010 1010 0011 1011 0100 1100 0101 1101
❶ 0000 0000 0000 0001 0010 1010
0011 1011 0100 1100 0101 1101
FF
FE
❷ 0000 0000 0000 0001 0010 1010 1111 1111 1111 1110 0011 1011 0100 1100 0101 1101
❸ 0000 0010 0000 0001 0010 1010 1111 1111 1111 1110 0011 1011 0100 1100 0101 1101
0201:2aff:fe3b:4c5d
Modifikovaný EUI-64 identifikátor
Zdroj: http://www.tcpipguide.com/free/t_IPv6InterfaceIdentifiersandPhysicalAddressMapping-2.htm
Obr. 02-05 Tvorba modifikovaného EUI-64 identifikátoru
Samotný modifikovaný EUI-64 identifikátor interfejsu je globálně jednoznačný a umožňuje
určit rozhraní v rozsahu celého Internetu. Modifikovaný EUI-64 identifikátor se používá
v globální unicast adresaci. Globální adresu lze sestavit automaticky principem automatické
konfigurace. Navíc modifikovaný EUI-64 identifikátor zůstává stejný i v případě mobility.
15
V tomto případě se mění jenom prefix sítě. Jedná se o situaci, kdy rozhraní se pohybuje,
například mobilní telefon.
V případě odposlechu na strategických místech v sítí lze zjistit, s kým zařízení komunikuje a
jak se geograficky pohybuje po světě. Proti tomuto druhu odposlechu není obrany principem šifrování, protože IP adresy musí zůstat otevřené.
Toto je považováno za zásah soukromí uživatele, i když je identifikováno rozhraní nikoliv
osoba. Této jednoznačné identifikaci mají zabránit dočasné identifikátory interfejsu podle
RFC 4941. Tento identifikátor je vygenerován náhodným způsobem a přiřazen rozhraní na
definovaný čas. Po tomto času se přiřadí nový dočasný identifikátor interfejsu. Modifikovaný EUI-64 identifikátor zůstává přiřazen rozhraní trvale. Internet je založen na principu
klient server. Proto klient navazující spojení okamžitě použije přidělený dočasný identifiká- Dočasný identitor. Avšak cílový uzel je nejdříve osloven trvalým modifikovaným EUI-64 identifikátorem a fikátor interfejsu
□
pokud má zájem, může spojení převést na dočasný. Proto v záznamech DNS je možné
uvádět pouze trvalé modifikované EUI-64 identifikátory, dočasné nelze.
Další možné identifikátory rozhraní jsou kryptograficky generované identifikátory podle RFC Kryptografický
3972. Tyto identifikátory mají zaručit vlastnictví identifikátoru a zabránit jeho podvrhnutí či identifikátor
přivlastnění útočníkem. Tyto identifikátory vycházejí z principu veřejného klíče.
interfejsu □
RFC 7136 z roku 2014 shrnuje problémy identifikátorem rozhraní. V průběhu IPv6 totiž
vznikly a byly vydány jako RFC identifikátory interfejsu, které popírají či nepoužívají U/L a Nejnovější RFC,
I/G bity. RFC 7136 se snaží vysvětlit a nalézt řešení.
popření □
2.4.2 Vyhrazené unikátní adresy
Nespecifikovaná adresa je nulová IP adresa ::, (0:0:0:0:0:0:0:0). Nulová adresa nesmí přiřazena žádnému uzlu sítě, protože indikuje, že uzel dosud nemá přiřazenou IPv6 adresu. Nespecifikovaná
Typickým příkladem je použití nulové adresy jako zdrojové adresy IPv6 paketech adresa □
v inicializačních protokolech, které přiřazují IPv6 adresu. Paket, který obsahuje nulovou IP
adresou, nesmí být směrován. Nulová adresa nesmí v žádném případě použita jako cílová
adresa v IPv6 paketu nebo jako směrovací hlavička IPv6.
Adresa lokální smyčky - Loopback address je unikátní IPv6 adresa ::1, (0:0:0:0:0:0:0:1).
Loopback je adresa, která ukazuje sama na sebe. Adresa lokální smyčky smí být použita Loopback adresa
□
uzlem k zaslání IP paketu sobě samému. Nesmí být přiřazena fyzickému rozhraní. Tato
adresa má lokální linkový dosah a může být chápana jako unikátní lokální linková adresa
virtuálního rozhraní. Toto virtuální rozhraní je připojeno k imaginární lince, která nevede
Prefix ::1/128 □
nikam. V unixových systémech typicky označováno jako lo nebo loØ.
Pokud je loopback adresa použita jako cílová adresa potom uzel odpoví sám sobě. Ale
adresa lokální smyčky nesmí být použita jako zdrojová IPv6 adresa v paketu, který je odesílán mimo uzel. IPv6 paket, kde cílová adresa je adresa lokální smyčky, nesmí být vyslán
mimo uzel a nesmí být směrován IPv6 směrovači. Pokud rozhraní přijme paket s cílovou IP
adresou loopback, potom paket musí být zahozen.
16
2.4.3 Lokální linková adresa
Lokální linková, Link-local unicast address, je adresa s prefixem fe8::/10. Unikátní linková
Lokální linková
adresa se skládá ze dvou 64 bitových části, obr. 02-06. První nejvýznamnější část je adresa
adresa □
sítě a je tvořena 10 bitovým prefixem, B1111 1110 10, a zbývajících 54 bitů první části je
rovno nule. Druhá 64 bitová část obsahuje identifikátor interfejsu.
127
10 bitů
54 bitů
1111 1110 10 0000…
…0000
64 bitů
Identifikátor interfejsu
0
Prefix fe80::/10 □
Obr. 02-06 Formát lokální linkové adresy
Typická unikátní lokální linková IPv6 adresa, kdy identifikátor interfejsu je modifikovaný
EUI-64 identifikátor je například
fe80::2123:45ff:fe67:89ab
Modifikovaný EUI-64 identifikátor interfejsu je odvozený od MAC adresy síťového rozhraní,
01-23-45-67-89-ab.
Jiná typická unikátní lokální linková IP adresa je s 64 bitovým identifikátorem. 64 bitový
identifikátor je přiřazen a unikátnost IP v6 adresy musí být ověřena.
RFC 7136 □
fe80::1234:5678
fe80::ff00:0:1
Jednoznačnost lokální unikátní adresy je omezena na linku a nesmí být směrována. Směrovače nesmí dál přenášet pakety s unikátní linkovou adresou na pozici zdrojové nebo cílové
adresy.
Význam unikátních lokálních adres spočívá v tom, že uzel je, že každý IPv6 uzel sítě je schopen tuto adresu sám sestavit s tím navázat spojení se svými sousedy. Tento princip se
hodně využívá při auto-konfiguraci uzlu.
2.4.4 Globální unicast adresa
Globální unicast adresa má všeobecný formát znázorněný na obr. 02-07. Globální směrovací
prefix je adresa přiřazena místu, které potom lze chápat jako cluster podsítí nebo linek.
Globální směrovací prefix je typicky hierarchicky strukturovaný. Dále, identifikátor podsítě
(subnet ID) je chápan jako identifikátor linky uvnitř místa. Poslední pole je identifikátor
rozhraní. Globální unicast adresy jsou dvojího druhu, s prefixem rovným b000 a prefixem
různým od b000. Příkladem globálních unicast adres s prefixem b000 jsou IPv6 adresy
s vloženou IPv4 adresou. Opakem, to je prefix různý od b000, jsou globální adresy s identifikátorem rozhraní 64 bitů dlouhým. Tyto adresy jsou blíže informačně popsány v RFC 3587.
17
127
n bitů
Glob ální směrovací p refix
m bitů
(128 - n – m) bitů
0
ID pod sítě
Obr. 02-07 Všeobecný formát globální unicast adresy
Na základě diskuzí IETF a RIR odborníků vznikla informace RFC 3587, která blíže specifikuje
RIR – Regional
hodnoty jednotlivých polí, obr. 02-08. Vše začíná definovaným prefixem b001, který definoInternet Registry
vala IANA. Globální směrovací prefix má 45 bitů, identifikátor podsítě 16 bitů a identifikátor □
rozhraní 64 bitů. Další poznatek je, že IANA přidělila RIR více prefixů, a další členění nechala
na nich. Tím je umožněno zohlednit různorodé požadavky malých, středních a velkých
zákazníků Internetu, požadavky na mobilitu. Tato volnost má zajistit agregaci adres za
účelem minimalizace směrovacích tabulek. Soupis globálních přidělených prefixů pro RIR
autority je na stránkách IANA, odkaz http://www.iana.org/assignments/ipv6-unicastaddress-assignments/ipv6-unicast-address-assignments.xml.
127
3
45 bitů
001
Glob ální směrovací
p refix
16 bitů
0
64 bitů
ID pod sítě
Uplatňovaný
formát globální
unicast adresy
podle RFC 3587 □
Obr. 02-08 Formát globální unicast adresy podle RFC 3587
Pro oblast dokumentace byl vyčleněn globální unicast prefix 2001:db8::/32, RFC 3849.
Definice tohoto prefixu má zabránit jakýmkoliv nedorozuměním a záměně příkladu v dokumentaci se skutečností. Prefix 2001:db8::/32 není směrován.
2001:db8::/32 □
2.4.5 IPv4 kompatibilní adresa s IPv6 - odmítnutá
Tato adresa patří do skupiny adres, které umožňují vložit IP verze 4 adresu do IP adresu
verze 6. IPv4 kompatibilní adresa má prefix ::/96, to značí 96 nul, za kterým následuje 32
bitová IPv4 adresa. Dnes je tato adresa odmítnutá.
2.4.6 IPv4 mapovaná adresa
Formát IPv4 mapované adresy je na obr. 02-09 a má prefix ::ffff/96. Od předcházející adresy
se liší umístěním 16 jedniček na konec prefixu. Za tímto prefixem následuje IPv4 adresa. IPv4 mapované
□
Mapovaná adresa obsahuje IPv4 adresu, která musí být veřejná, aby se zachovala unikát- adresa
nost unicast IPv6 adresy.
127
80 bitů
000000…
16 bitů
…0000
ffff
32 bitů
0
IPv4 adresa
Obr. 02-09 Formát IPv4 mapované adresy do IPv6
18
Zápis této adresy má doporučený formát zápisu podle RFC 5952 jako mixovaný. Úvod se
zapisuje podle pravidel verze 6, samotná IPv4 adresa se zapisuje v tečkové notaci. To je
dekadické hodnoty bytů oddělených tečkou. IPv4 adresa 123.145.167.189 se jako mapovaná adresa v prostoru IPv6 zapisuje jako ::ffff:123.145.167.189.
2.4.7 Místní lokální unikátní adresa - odmítnutá
Místní lokální unikátní adresa, Site-Local IPv6 Unicast Address, je dána prefixem fec0::/10 a
odmítnutá. Podle RFC 4291 se nesmí používat v nových nasazeních. Je zde uvedena pro
úplnost, a je nahrazena unikátní linkovou IPv6 adresou, Unique Local IPv6 Unicast Addresses.
2.4.8 Unikátní lokální adresa
Unikátní lokální adresa, Unique Local IPv6 Unicast Addresses, je dána RFC 4193 z roku 2005.
Rozsah platnosti této adresy je místo – site a základní prefix unikátní lokální adresy je Unikátní lokální
adresa □
fc00::/7. Další pole lokální adresy jsou na obr. 02-09.
127
7 bitů
1111 110 L
40 bitů
G l o b á ln í I D
16 bitů
P od s íť I D
64 bitů
0
Prefix fc00::/7 □
Obr. 02-09 Formát unikátní lokální adresy
Lokální přiřazení□
Za prefixem následuje jednobitový příznak L, který indikuje lokální přiřazení. Zatím tento
příznak L bude nastaven na 1 - lokální přiřazení. Hodnota 0 je rezervovaná pro budoucí
použití. Zároveň lokální přiřazení značí, globální identifikátor je generován pseudonáhod- Globální identifiným algoritmem v souladu s RFC 4193 a RFC 4086 - Randomness Requirements for Securi- kátor je pseudoty. Pseudonáhodný způsob generování globálního identifikátoru umožňuje vygenerovat náhodné číslo□
dva stejné identifikátory s danou pravděpodobností. Vzorec pravděpodobnosti je v RFC
4193, sekce 3.2.3. Pokud bude generováno 10 globálních identifikátorů, potom s pravděpodobnosti 4,54 * 10-11 dojde ke kolizi. V případě 1 000 globálních identifikátorů je pravděpodobnost kolize 4,54 * 10-7, RFC 4193.
Další pole je identifikátor podsítě, který je již přidělován správcem místa. Poslední pole
identifikátor rozhraní.
Prakticky se doporučuje dosah unikátní lokální adresy na jedno místo. A platí, že jedno
místo může mít vygenerováno více globálních identifikátorů a každý globální identifikátor
může být členěn na podsítě. I když defaultně, dosah unikátní lokální adresa je globální, a
unikátní linkové adresy jsou považovány za globálně unikátní. Unikátní lokální adresa obsahuje identifikátor podsítě stejně jako globální unikátní adresa. Očekává se, že tento identifikátor bude sdílen a oba typy adres budou používány současně.
Omezení unikátní lokální adresy je ve směrování a související pravidla se váži uvnitř místa,
Směrování
na hranice místa, a mimo místo. Směrování v rámci místa není nijak omezeno. Problém
unikátní lokální
jenom nastává, když místo tvoří dva nebo více geograficky oddělených celků, které nejsou
adresy□
19
propojeny sítí majitele místa. Potom k propojení lze použít poskytovatele Internetu a propojení zajistit na základě vzájemné smlouvy. Na těchto propojeních lze používat unikátní
lokální adresu.
Každé místo je ohraničeno směrovači popřípadě firewally. Tyto uzly nesmí dále šířit unikátní
adresy s prefixem fc00::/7 mimo místo. Jedná se o adresy jak zdrojové, tak i cílové unikátní
lokální adresy. Tyto hraniční uzly mohou přenášet mimo místo pouze unikátní adresy
s prefixem 48 bitů.
Směrovače mimo místo nesmí šířit pakety se zdrojovou nebo cílovou unikátní lokální adresou s prefixem fc00:/7. Pouze na základě dohod lze směrovat unikátní lokální adresy se 48
bitovým prefixem.
Pokud uzly nebudou dále směrovat paket s cílovou unikátní lokální adresou, měly by o této
skutečnosti informovat zdrojový uzel a to formou ICMPv6 zprávy o nedosažitelnosti cíle ICMPv6 Destination Unreachable message. Tato zpětná odezva je důležitá, aby se zabránilo
timeout-ům transportního protokolu - transport protocol timeouts.
Poznámka k pojmu dosah místo – site-local scope
Podle RFC 4291 je dosah místo zamýšlen jako jedno místo. Vyšší dosah je organizace, která
se skládá z více míst. Z toho vyplývá, že konkrétní dosah místo není přesně vymezen a
určuje jej správce sítě. □
Předpokládá se, že s IPv6 adresami se bude pracovat pomocí jmen. Ale RFC 4193 nedoporučuje uvádět AAAA a PTR záznamy s unikátními lokálními adresami do globálního DNS sys- DNS a unikátní
tému. To samé platí o reverzním překladu, adresu na jméno. I když unikátní lokální adresy lokální adresy□
jsou považovány za globálně unikátní, je zde určitá malá pravděpodobnost, že jedna unikátní lokální adresa bude přidělena dvěma různým místům.
Linková lokální adresa se přiřazuje hostovi automaticky podle daného algoritmu. Přiřazení
unikátní lokální adresy však musí být zajištěno DHCPv6 serverem nebo oznámením směrovače – router advertisement. Problematika jmen může býti řešena lokálním DNS systémem.
Proto RFC 4193 doporučuje unikátní lokální adresy pouze v rámci místa.
Aplikace lokálních adres v rámci místa může přinést i bezpečnostní výhody. Nutno si uvědomit, že ne všechny uzly sítě musí být dostupné z vnějšku. Uzly, které mají býti dosažitelné
pouze v rámci místa, budou mít přidělenou pouze lokální adresy a takto zaneseny do lokálního DNS systému. Uzly, které budou součásti globálního Internetu, pak budou mít přiřazeny lokální i globální adresy.
2.5 Anycast adresy
Výběrové adresy – anycast adresy představují nový způsob adresování. Jedná se o situaci,
kdy jedna unikátní adresa je přiřazena více fyzickým uzlům. Datagram s výběrovou adresou Výběrové adresy
těchto uzlů bude doručen pouze jednomu z nich a to topologicky nejbližšímu. Účelem □
těchto adres je docílit rozprostření zátěže sítě a serverů po celé sítí. Aplikace výběrových
20
adres začala u kořenových DNS serverů. Tento způsob adresování byl zaveden nejdříve v IP
protokolu verzi 6 a posléze nasazen i v protokolu IP verze 4.
n bitů
127
Prefix podsítě
0
128 - n bitů
…000
000…
Obr. 02-10 Základní formát anycast adresy, RFC 4291
Formát výběrové adresy podle RFC 4291 je na obr. 02-10. Výběrové adresy používají pouze
prefix sítě, identifikátor rozhraní je nulový. Prefix podsítě určuje specifickou linku. Bližší
informace v RFC 4291.
2.6 Multicast adresy
Skupinová adresa – multicast address je adresa přiřazená skupině rozhraní převážně na
různých hostech. Zároveň jedno rozhraní může přináležet do více skupin. Formát multicast Skupinové
adresy podle RFC 4291 je na obr. 02-11. Skupinové adresy mají update RFC 7371 z roku
adresy □
127
8 bitů
4
1111 1111
4
flgs scop
112 bitů
0
Identifikátor skupiny
X Y P T
Obr. 02-11 Formát multicast adresy podle RFC 4291
Jednotlivé pole jsou:



Úvodní prefix b1111 1111.
flgs – 4 bitové pole příznaků, kde jednotlivé bity jsou označeny 0RPT.
 X je nově definováno RFC 7371, a může mít hodnotu 0 nebo 1
 Y je nově definováno RFC 7371
 P = 0, adresa nevychází ze síťového prefixu, blíže RFC 3306.
 P = 1, adresa vychází ze síťového prefixu, blíže RFC 3306.
 T = 0, značí, že multicast adresa je permanentně přiřazena. Je také označována jako „dobře známa“ adresa a je přiřazena autoritou IANA.
 T = 1, značí, že multicast adresa není permanentně přiřazena. Je také označována jako „přechodná“ nebo „dynamická“ skupinová adresa. V praxi to
značí vytvoření uživatelské skupiny.
 Když je P = 1 potom musí být i T = 1.
scop – pole dosahu – scope. Dosah skupinové adresy udává vzdálenost mezi jednotlivými členy skupiny. Jednotlivé hodnoty dosahu podle RFC 4291 jsou:
 0 – rezervováno
 1 - Interfejs, lokální smyčka - Interface-Local scope.
 2 – lokální linkový dosah - Link-Local scope.
21
Update
RFC 7371 □
Dosah skupinové
adresy □


3 – lokální oblastní dosah – realm local scope, RFC 7346, rok 2014. Původně
tento dosah byl podle RFC 4291 rezervován.
 4 – lokální administrátorský dosah - Admin-Local scope.
 5 – lokální dosah místa - Site-Local scope.
 6 – nepřiřazeno
 8 – lokální dosah organizace - Organization-Local scope.
 A – nepřiřazeno
 B – nepřiřazeno
 C – nepřiřazeno
 D – nepřiřazeno
 E – globální dosah - Global scope.
 F – rezervováno
Identifikátor skupiny, je 112 bitové pole, které identifikuje skupinu. Tento identifikátor se přiřazuje permanentně nebo dočasně. Členění identifikátoru skupiny na
další pole je možné a závisí od typu skupinové adresy, blíže RFC 3306.
Poznámka k chápání příznaků podle RFC 7371
Původně, RFC 3306 a RFC 4291 uvádí příznaky 0, R, P a T. Avšak některé aplikace a dokumenty chápou tuto skupinu příznaků jako číslo, a ne jako oddělené bity, příznaky.
RFC 7371 uvádí, že příznaky X, Y, P a T musí být chápany jako samostatné bity.
Mezi konkrétními hodnotami dosahů existují hodnoty dosahů, které jsou označené jako
rezervováno a nepřiřazeno. Dosah rezervováno se nesmí použit. Naproti tomu dosah nepřiřazeno je určen pro správce sítě, kteří jej mohou použít. Základem je, nově přiřazený dosah
správcem by měl pokrývat zvětšenou část sítě. Příkladem je síť CESNET 2 a další evropské
akademické sítě, kde je definován dosah A, který pokrývá danou národní akademickou síť.
V zápisu skupinové adresy je pole dosah volitelné a zbývající pole jsou konstantní a jednoZápis s písznačně daná. Z důvodu zkrácení zápisu všech možných variant, bylo zavedeno používání
menem „x“
písmena „x“ pro pole dosah. Potom lze skupinovou adresu zapsat nehledě na dosah násleff0x:: □
dovně
ff3x:0040:2001:db8:1001:2c6:1:2:3
nebo
ff3x:0030:2001:db8:1001:0:1:2:3.
Permanentní skupinové adresy jsou přiděleny RFC a jejich význam závisí od dosahu. Tyto
adresy jsou také označovány jako vyhrazené skupinové adresy. Tyto adresy se vyznačují Permanentní
prefixem ff0x::/12, všechny příznaky jsou nulové, XYPT = 0x0. Jedná se o „dobře známe adresy □
skupinové adresy“. Právě tyto adresy nahrazují broadcast adresaci. Dosah potom definuje,
až kam se datagram s touto cílovou adresou může šířit. Velice známy je příklad s NTP serve22
ry – Network Time Protocol. Tyto servery mají permanentně přidělený identifikátor skupiny
::101. Potom lze sestavit následující permanentní skupinové adresy, RFC 4291:




ff01::101, skupina obsahuje všechny NTP servery na daném síťovém rozhraní. Adresa ukazuje na sebe sama. Lze také hovořit o a NTP server na adrese ::1.
ff02::101, jedná se o všechny NTP servery na lince, na které je umístěn zdroj paketu. Dá se konstatovat, že se jedná o podsíť, a zdroj paketu je členem této podsítě.
ff05::101, jedná se o všechny NTP severy v rámci místa, kterého zdroj paketu je členem.
ff0e::101, jedná se o všechny NTP servery v globálním dosahu. Jedná se vlastně o
celý Internet.
Nepermanentně přiřazené skupinové adresy mají příznak T roven jedné a mají význam
pouze v daném dosahu. Například, nepermanentní skupinová adresa ff15::101 má dosah Ne-permanentní
□
místo a 101 je nepermanentní identifikátor skupiny. Jedná se o nepermanentní místně adresy
lokální skupinovou adresu. Identifikátor skupiny nemá žádný vztah ke skupině, která má
stejnou adresu ale v jiném místě. Ani k nepermanentní skupině 101 ale s jiným dosahem.
Dokonce ani k permanentní skupině se stejným dosahem. Z toho vyplývá, že adresy
ff14::101 a ff15::101 jsou dvě samostatné adresy a tím i dvě oddělené skupiny. Dále adresa
ff15::101 nemá nic společného s adresou ff05::101. Jsou to dvě rozdílné adresy, ukazující na
dvě různé skupiny, první je nepermanentní adresa a druhá je permanentní adresa.
Skupinová adresa nesmí být použita jako zdrojová adresa v IP paketu a také nesmí být Podmínky směpoužita jako směrovací hlavička - Routing header. Směrovače nesmí přenášet pakety rování □
s cílovou multicast adresou mimo definovaný rozsah v adrese. Dále uzly nesmí sestavovat
pakety s rezervovaným dosahem 0, pokud je takovýto paket přijat, potom musí být tiše
zahozen (silently dropped). Dále, uzly by neměly sestavovat pakety s dosahem F. V případě,
že je takovýto paket vyslán nebo přijat, potom musí být s ním zacházeno jako s paketem
obsahující skupinovou adresu s dosahem E, celý Internet.
Výše uvedená definice formátu skupinové adresy definuje identifikátor skupiny dlouhý 112
bitů. Ale další definice skupinových adres využívají část tohoto pole k definici dalších polí.
RFC 3307 tyto skutečnosti zohledňuje a definuje identifikátor skupiny jako 32 bitový
s následujícím rozdělením:



0 až 3fff:ffff
4000:0000 až 7fff:ffff
8000:0000 až ffff:ffff
skupiny přidělované IANA
identifikátory přidělené IANA
dynamické, volně k použití
Do první skupiny 0 až 3fff:ffff spadají celé skupinové adresy, například ff0x::101 - NTP servery. Nebo skupinové adresy pro všechny směrovače, ff01::2, ff02::2 a ff05::2, kdy jiné dosahy
nejsou dovoleny. Do druhé skupiny patří adresy, kde IANA definuje identifikátor skupiny
s libovolným prefixem. Předpokládá se jejich použití pro skupinové adresy odvozené od
individuálních adres.
23
2.6.1 Před-definované skupinové adresy
Permanentně přiřazené adresy jsou spravovány autoritou IANA. Celý soupis těchto adres lze
najít na [IANA_0201]. RFC 4291 uvádí před-definované adresy, které jsou svázané s kon- Předefinované
krétním dosahem. Použití identifikátoru skupiny v jiném než definovaném rozsahu a skupinové
□
s příznakem T rovným nule není dovoleno. RFC 4291 uvádí permanentně před-definované adresy
skupinové adresy s následujícími dosahy a pro skupiny:




❶
&
|
❷
❸
Identifikátor skupiny 0. Všechny adresy s identifikátorem skupiny rovným nule a pro
všechny dosahy jsou považovány za rezervované. Tyto adresy by neměly býti přiřazeny žádné skupině. Jedná se o adresy: ff00::, ff01::, ff02::, ff03::, ff04::, ff05::,
ff06::, ff07::, ff08::, ff09::, ff0a::, ff0b::, ff0c::, ff0d:: ff0e:: a ff0f::.
Adresa pro všechny uzly. Identifikátor skupiny pro všechny uzly sítě bez rozdílu je
roven 1, ale povolený dosah je omezen na rozhraní a linku.
 ff01::1, jedná se o skupinovou adresu všech uzlů v dosahu síťového rozhraVšechny uzly□
ní.
 ff02::1, jedná se o skupinovou adresu všech uzlů na lince.
Adresa pro všechny směrovače. Identifikátor skupiny směrovačů je roven 2 a povolené dosahy jsou 1, 2 a 5.
 ff01::2, směrovače v rámci jednoho rozhraní
Všechny
 ff02::2, směrovač v rámci linky
směrovače□
 ff05::2, směrovače v rámci místa
Adresa pro vyzývaný uzel - Solicited-Node Address. Tyto skupinové adresy se odvoAdresa pro
zují přímo v uzlu na základě unicast a anycast adresy uzlu. Skupinová vyžádaná advyzývaný
resa uzlu vzniká zřetězením prefixu ff02::1:ff00/104 s nejméně významovými 24 biuzel□
ty unicast nebo anycast adresy. Výsledkem zřetězení je vyžádaná skupinová adresa
uzlu v rozmezí od ff02::1:ff00:0 až ff02::1:ffff:ffff.
2001:0db8:1001:0123:fedc:ba98:7654:3210
2001 0db8 1001 0123 fedc ba98 7654 3210
0000 0000 0000 0000 0000 0000 00ff ffff
0000 0000 0000 0000 0000 0000 0054 3210
ff02 0000 0000 0000 0000 0001 ff00 0000
IP adresa
128 bitové slovo
128 bitová maska
128 slovo odvozené od
prefixu
ff02 0000 0000 0000 0000 0001 ff54 3210
ff02::1:ff54:3210 Kanonický zápis IP adresy
❹
Obr. 02-12 Výpočet vyžádané skupinové adresy uzlu
Uzel má unicast adresu 2001:db8:1001:123:fedc:ba98:7654:3210 potom skupinová vyžádaná adresa uzlu je ff02::1:ff54:3210. Ukázka výpočtu je na obr. 02-12. Výpočet je realizován
pomocí následného algoritmu:


Všechny výpočty se provádějí na 128 bitovém slovu.
S adresy se principem masky získá nejméně významových 24 bitů. Aplikuje se bitová
operace logického násobení „&“, C jazyk.
24


Provede se zřetězení s prefixem ff02::1:ff00:0/104. Aplikuje se bitové logická operace součtu „|“, C jazyk.
Zápis vzniklá adresy v kanonickém formátu.
Je požadováno, aby uzel na každém rozhraní a všechny přiřazené unicast a anycast adresy
k danému rozhraní vypočetl skupinové vyžádané adresy uzlu. Takto vypočtené adresy
přiřadí k danému síťovému rozhraní. Tento vypočet je nutno udělat pro všechny síťová
rozhraní uzlu.
2.6.2 Skupinové adresy vycházející z unicast adres
Základní formát skupinové adresy je zopakován na obr. 02-13, kde skupina je definovaná
Multicast ze
112 bitovým identifikátorem. Tento identifikátor může být generován automaticky a proto
směrovacího
je nutná jeho kontrola na jednoznačnost. Kontrola jednoznačnosti je náročná, protože
prefixu □
každá skupina má definovaný dosah, který ještě vnáší další úvahy. Aby, se zabránilo těmto
problémům, je definována skupinová adresa vycházející z unicast adresy. Tím se omezí
platnost identifikátoru skupiny na síťový prefix unicast adresy.
127
8 bitů
4
1111 1111
0
112 bitů
4
Identifikátor skupiny
ff1 scop
X Y P T
Obr. 02-13 Základní formát skupinové adresy
Skupinová adresa vycházející z unicast adresy nebo skupinové adresy vycházející ze síťového
Unicast-Prefixprefixu - Unicast-Prefix-based IPv6 Multicast. Tato adresy se vyznačují hodnotou příznaků P
based IPv6
= 1 a T = 1. Potom prefix skupinové adresy, která vychází ze síťového prefixu je ff3x::/12.
Multicast□
Význam pole dosahu se nemění. Nastavení pole příznaků má význam:





127
X je nově definováno RFC 7371
Y je nově definováno RFC 7371 a význam je podle RFC 3952 – rendezvous point
P = 1, adresa je odvozena od prefixu síťového prefixu
T = 1, adresa je dočasná
Když je P = 1 potom musí být T = 1
8 bitů
4
1111 1111
4
4
4
ff1 scop ff2 rsvd
8 bitů
plen
64 bitů
32 bitů
prefix sítě
ID skupiny
0
0000
P = 1 a T = 1  Skupinová adresa vycházející z unicast
adresy
Obr. 02-14 Základní formát skupinové adresy
X Y P T
Původní pole identifikátoru skupiny obsahuje část síťového prefixu globální unicast adresy.
Detailní formát skupinové adresy vycházející ze síťového prefixu je na obr. 02-14 a význam
jednotlivých polí je následující:

ff1, je pole příznaků 1, flag field 1 a obsahuje příznaky X, Y, P a T, RFC 7371
25








X je nově definováno RFC 7371
Y je nově definováno RFRC 7371 a význam je dán RFC 3956 jako příznak R –
rendezvous point
 Když je příznak P = 1 potom musí být T = 1
scop, je pole odpovídající dosahu
ff2, je pole příznaků 2, flag field 2, jednotlivé příznaky jsou označeny „rrrr“ a jejich
hodnota je zatím nula a je rezervována pro budoucí použití, RFC 7371
rsvd, reserved, je 4 bitové rezervované pole a musí mít hodnotu 0x0
plen, je pole udávající délku síťového prefixu v následujícím poli
prefix sítě, je 64 bitové pole pro umístění síťového prefixu z unicast adresy, použitý
síťový prefix nemusí být dlouhý 64 bitů a v tom případě je doplněn nulami zprava
ID skupiny je 32 bitové pole identifikátoru skupiny
Organizace má globální prefix pro unicast adresu 2001:db8:abc::/48. Řekněme, že z tohoto
prefixu chceme odvodit skupinovou adresu vycházející ze síťového prefixu s dosahem
organizace, scope = 8. Identifikátor skupiny bude 11 dekadicky. Výsledkem bude adresa
skupinová adresa vycházející z unicast adresy tato ff38:0030:2001:db8:abc::b. V případě 50
bitového prefixu sítě, například 2001:db8:abc:8000::/50, skupinové adresy s dosahem
lokální linka, scope = 2 a identifikátorem skupiny 11 dekadicky, bude celá skupinová adresa
vycházející z unicast adresy ff32:0032:2001:db8:abc:8000::b.
RFC 3306 definuje speciální adresy označené jako Source Specific Multicast. Tyto adresy
jsou odvozené z výše uvedené multicast adresy vycházející z unicast adresy s tím, že pole Adresy SSM –
délka prefixu a samotný prefix jsou nulové. Skupinové adresy SSM mají prefix ff3x::/96, kde Source Specific
Multicast□
x značí hodnotu dosah. Za tímto prefixem následuje identifikátor skupiny, obr 02-15.
127
8 bitů
4
1111 1111
4
4
4
ff1 scop ff2 rsvd
8 bitů
plen
0000 0000 0000 0000 000…
64 bitů
32 bitů
prefix sítě
ID skupiny
0
Prefix ff3x::/96□
…000
X Y R P P = 1 a T = 1  Skupinová adresa vycházející z unicast
T
Obr. 02-15 Základní formát skupinové adresy SSM
Skupinové adresy SSM jsou určeny pro přenosy dat z jednoho zdroje skupině příjemců.
Předpokládané použití je pro internetové rádio či televize. K zajištění jednoznačnosti pomáhá princip právě jednoho zdroje, to značí jednoznačná zdrojová adresa v hlavičce IPv6
paketu. Z toho se dá usuzovat, že jedna zdrojová adresa může vysílat až 32 různých programů. Jeden konkrétní program je potom dán dvojici adres, zdrojová adresa odesílatele a
skupinová adresa SSM, identifikátor skupiny specifikuje daný program.
26
2.6.3 Skupinové adresy vycházející z rozhraní.
Skupinové adresy vycházející z rozhraní - Link-Scoped IPv6 Multicast, rozšiřují možnosti
vytváření a použití skupinové adres. Unikátnost této skupinové adresy je omezena na rozhraní a lokální linku. Identifikátor rozhraní je unikátní na lince a tím je zajištěna unikátnost
skupinové adresy.
Na základě toho, jsou skupinové adresy vycházející z rozhraní preferované před adresami
vycházející z unicast prefixu, RFC 3306. Aplikace identifikátoru rozhraní umožnuje tyto
adresy generovat automaticky bez přiřazení alokačním serverem. Tato metoda přiřazení je
lepší než aplikace adres založených na prefixu unicast adresy s aplikacemi v prostředí bez
serverů. Příkladem takovýchto sítí mohou být ad-hoc sítě a síťová mobilita.
127
8 bitů
4
1111 1111
4
4
4
ff1 scop ff2 rsvd
8 bitů
plen
64 bitů
32 bitů
ID rozhraní
ID skupiny
0
0000 0000 1111 1111
X Y P T P = 1 a T = 1  Skupinová adresa vycházející z unicast
Obr. 02-16 Základní formát skupinové adresy vycházející z rozhraní
Formát skupinové adresy vycházející z rozhraní je dán RFC 4489 a je na obr. 02-16. Význam
jednotlivých polí je následující:







ff1, je pole příznaků 1, flag field 1 a obsahuje příznaky XYPT, RFC 7371
 X je nově definováno RFC 7371, a může mít hodnotu 0 nebo 1
 Y je nově definováno RFC 7371
scop, je pole odpovídající dosahu
ff2, je pole příznaků 2, flag field 2, jednotlivé příznaky jsou označeny „rrrr“ a jejich
hodnota je zatím nula a je rezervována pro budoucí použití, RFC 7371
rsvd, reserved, je 4 bitové rezervované pole a musí mít hodnotu 0x0
plen = 0xff, pole, které musí mít samé jedničky, původně určovalo délku
ID rozhraní, pole odpovídající identifikátoru rozhraní
IP skupiny, pole identifikátoru skupiny
Z definice polí skupinové adresy jasně vyplývá, že může být sestavena automaticky rozhraním podle předem daného algoritmu. K sestavení nejsou potřebné žádné další informace,
než kterými rozhraní disponuje. /Platnost adresy je pouze v dosahu rozhraní a lokální linky.
27
Předpokládejme, že rozhraní má lokální unicast linkovou adresu fe80::123:456:abc. Identifikátor skupiny je 19 dekadicky. Potom skupinová adresa vycházející z rozhraní pro linkový
dosah je ff32:00ff:0:123:456:abc::13.
2.6.4 Skupinové adresy s rendezvous point
Princip multicast adresa značí doručit pakety všem členům skupiny. Zvažme situaci podle
obr. 02-16, kdy zdroj multicast adresace je hodně vzdálen od členů skupiny. Otázky jsou,
zda pro každého člena skupiny má být ze zdroje vyslán jeden paket. Nebo zda paket má být
vyslán ke každému hostovi, při globálním dosahu to určitě budou zajímavé počty. Ale,
naskýtá se řešení vytvořit v blízkosti shromaždiště - rendezvous point, RP.
2.7 Požadované adresy uzlu
Nutno si uvědomit, že jedno rozhraní uzlu může mít libovolný počet IP adres. V IP protokolu
verze ž se definují povinné adresy, které musí být přiřazeny. RFC 4291 definuje následující
adresy, které musí být přiřazeny hostu:






Lokální linková adresa pro každé rozhraní
Všechny unicast a anycast adresy, které mu byly přiděleny rozhraní uzlu a to manuálně nebo automaticky
Adresa lokální smyčky, typicky se přiřazuje virtuálnímu rozhraní
Všechny skupinové adresy pro všechny rozhraní a linky
Skupinová adresa pro vyzývaný uzel - Solicited-Node Multicast Address, pro každou
unicast a anycast adresu uzlu
Skupinové adresy všech ostatních skupin, do kterých uzel patří
Ukázkový příklad přiřazení IPv6 adres pro jedno rozhraní hosta je na obr. 02-17. Nutno
podotknout, že adresa není odvozena od fyzické MAC adresy rozhraní.
Lokální linková adresa
Přidělené unicast a
anycast adresy
Skupinová adresa uzlů
s dosahem rozhraní
s dosahem linka
Skupinová adresa pro
vyzývaný uzel
Další přiřazené skupinové adresy
fe80::ec67:4f8:37ce:995a
2001:db8:123:abc:ec67:4f8:37ce:995a
2001:db8:123:789:ec67:4f8:37ce:995a
ff01::1
ff02::1
Přidělené adresy
k rozhraní na hostovi
ff02::1:ffce:995a
ff15::ac04
Obr. 02-17 ukázka přidělených IPv6 adres rozhraní na hostu
28
Poznámka k hostu
Hostem se chápe uzel sítě, který poskytuje informace, služby a aplikace uživatelům nebo
ostatním uzlům v sítí, [wiki_0209]. Typický host je server, klientský počítač. Naproti tomu
hostem není směrovač, mode, tiskárna apod.
V případě směrovače jsou povinné adresy daná povinnými adresami hosta a následujícími:



Anycast adresy pro směrovač v podsíti, které se přiřadí pro všechny rozhraní, kde
směrovač pracuje jako směrovač
Všechny ostatní výběrové adresy, pro které je směrovač konfigurován
Všechny předdefinované skupinové adresy pro směrovače
anycast adresy
s dosahem rozhraní
s dosahem linka
vyzývaný uzel
Směrovače v podsíti
Směrovače v podsíti
Vyzývaný uzel
Přidělená anycast
adresa
Přidělená anycast
adresa
Vyzývaný uzel
Všechny směrovače na
rozhraní
Všechny směrovače na
lince
Všechny směrovače v
místě
fe80::ec67:4f8:37ce:995a
2001:db8:123:abc:ec67:4f8:37ce:995a
2001:db8:123:789:ec67:4f8:37ce:995a
ff01::1
ff02::1
Přidělené adresy
k rozhraní jako u hosta
ff02::1:ffce:995a
ff15::ac04
2001:db8:123:abc:ec67:4f8:37ce:995a
2001:db8:123:789:ec67:4f8:37ce:995a
ff02::1:ff00:0
2001:db8:123:abc:fdff:ffff:ffff:fffe
2001:db8:123:789:fdff:ffff:ffff:fffe
ff02::1:ffff:fffe
Adresy související
s funkcí směrovače
ff01::2
ff02::2
ff05::2
Obr. 02-18 Ukázka přidělených IPv6 adres rozhraní na směrovači
29
Na obr. 02-18 je prezentován soupis přidělených IPv6 adres směrovači. Je zde předpokládáno, že host byl překonfigurován na směrovač. Původní adresy související s hostem byly
rozšířeny o adresy potřebné pro směrovač.
2.8 Dosah adres
Je to nový pojem, který je definován u IP protokolu verze 6 a souvisí s multicast adresami.
Dosah definuje rozsah sítě, ve kterém se adresa může šířit a je unikátní. Pokud cílová adresa Dosah - scope□
v paketu má dosah, potom směrovače nesmí připustit šíření paketu mimo tento dosah.
Dosahy je definován RFC 4291 a RFC 7346 následně:









Dosah 1, rozhraní, lokální smyčka - Interface-Local scope. Je to nejmenší dosah, který vlastně neopouští síťový adaptér. Uzel sítě, jako celek, není součástí dosahu rozhraní, ale pouze adaptér je součásti dosahu. Pokud uzel má více síťových adaptérů,
potom má stejný počet dosahů velikosti rozhraní.
Dosah 2, lokální linkový dosah - Link-Local scope. Linka se zde chápe jako podsíť.
Linka se tím pádem vyznačuje směrovacím prefixem. Jinak, aplikace přepínačů nevytváří linky, protože přepínač pracuje s fyzickými adresami rozhraní, to je linkové
vrstvě TCP/IP modelu.
Dosah 3 – lokální oblastní dosah – Realm local scope. Tento dosah se odvozuje od
konkrétní sítě a je předpokládáno, že se bude týkat technologii „ IPv6 over foo“.
Přesný rozsah tohoto dosahu má být specifikován příslušným RFC a registrován u
IANA. Tento dosah je specifikován teprve od roku 2014, RFC 7346. Původně tento
dosah byl podle RFC 4291 rezervován.
Dosah 4 – lokální administrátorský dosah - Admin-Local scope. Jedná se o nejmenší
dosah, který musí být manuálně konfigurován. Tento dosah nejde automaticky odvodit z fyzické topologie či dalších informací o sítí.
Dosah 5 – lokální dosah místa - Site-Local scope. Jedná se o dosah, který pokrývá
jedno místo. Jak je vidět, tento dosah je volně definován a proto hranice definuje
správce sítě při zohlednění dosahu organizace.
Dosah 8 – lokální dosah organizace - Organization-Local scope. Jedná se o dosah
pokrývající více míst., které patří jedné organizaci.
Dosah E – globální dosah - Global scope. Jedná se od dosah pokrývající celý Internet.
Rezervované dosahy 0 a F – reserved. Podléhají organizaci IANA.
Nepřiřazené dosahy 6, 7, 9, A, B, C, D – unassigned. Tyto dosahy jsou dostupné pro
administrátory, aby definovali dodatečné multicast regiony. Je předpokládáno, že
rozsah sítě se vzrůstajícím dosah se bude zvětšovat, popřípadě zůstane stejný, nikoliv menší.
 Dosah A, pokrývající národní síť. Tento dosah je definován pro evropské národní akademické sít2. Dosah A v síti CESNET2 pokrývá celou tuto národní
síť, [Satrapa_2011].
Definice hranic jednotlivých dosahů se stanovují podle RFC 7346 jednak podle fyzického
propojení nebo podle administrátorského členění. Administrátorské hranice vlastně definuje správce sítě nebo v zastoupení poskytovatel Internetu. Nejnižší dosahy se odvozují od
30
Dosah 1□
Dosah 2□
Dosah 3□
Dosah 4□
Dosah 5□
Dosah 8□
Dosah E□
fyzického propojení sítě nebo od jiných konfigurací, které se nevztahují k multicast adresaci.
Jedná se o dosahy lokálního rozhraní (1), lokální linky (2), lokální oblast (3). Výší dosahy jsou
odvozeny od administrátorského členění s tím, že globální dosah (E) nemá hranice. Jedná se
o dosahy lokální administrátorský dosah (4), lokální místo (5) a lokální organizace (8).
Ukázka dosahů v sítí je na obr. 02-19. Dosah a rozhraní a linka je dán topologii sítě. Oblastní
dosah není zakreslen, protože souvisí s hlavně s principem „IPv6 over“ a je dán RFC. Vyšší
dosahy od 4 – administrátorský jsou již definovány správce sítě a vlastně závisí na jeho
rozhodnutí. Základním požadavkem však je, aby byla dodržena vzestupnost dosahů, popřípadě stejnost.
Internet, globální dosah
Linka A
Linka D1
Linka D4
Linka D2
Linka D3
1. linka
2. linka
Místo
A
5 – Místo A
Místo D
Linka D5
5. linka
3. linka
4. linka
Místo
B
5 – Místo B
6. linka
Místo Organizace
C
Strom
5 – Místo C
Žlutý kruh vymezuje lokální dosah rozhraní
Obr. 02-19 Ukázka dosahů
V naší ukázkové síti lze vést hodně polemik, protože ne vždy známe konkrétní zapojení
nadřízené sítě. V případě malé organizace či soukromého připojení lze pouze jednoznačně
definovat rozhraní a linku, kdy hranice jsou dány fyzickým propojením. Na obrázku se jedná
o linku A. Linkový dosah by mohl být i administrátorský dosah, což je přirozené, protože
každá takováto malá síť by měla mít správce. Definice vyšších dosahů by již závisela na vyšší
topologii propojení a poskytovateli Internetu. Jako správce malé sítě nemusím o tom hodně
vědět ani mít možnost rozhodovat.
Další zajímavou polemiku lze vést o místech A, B a C a definici administrátorského dosahu.
Definice místa je volná a závisí na správci sítě, který by měl vzít v úvahu, zda se bude defi- Unique Local
novat dosah organizace. Je předpoklad, že na v rámci místa budou aplikovány unikátní IPv6 Unicast
lokální IPv6 unicast adresy. Na obrázku jsou zakreslena místa B a C, jako samostatné zóny. Addresses, □
prefix fc00/7
31
Nic nebrání jejich sloučení do jednoho místa, vše závisí od správce. Zůstává administrátorský dosah, který není zakreslen. Zde by se spíše hodilo ztotožnění administrátorského
dosahu s místem.
Dosah organizace se skládá z více míst. Definice nic neříká o jejich propojení ani o geografickém rozmístění. Dá se předpokládat, že dosah organizace budou využívat velké společnosti či poskytovatel Internetu. Organizace již zajištuje propojení míst buď vlastními linkami,
nebo veřejným Internetem. Opět, dosah organizace definuje správce. Opět se dá předpokládat aplikace unikátních lokálních IPv6 unicast adres, které dokážou propojit jednotlivé
místa v rámci organizace.
2.9 Zóna
S dosahem úzce souvisí pojem zóna. Jedná se o část topologie sítě, která odpovídá dosahu.
Základní podmínkou je jednoznačnost adres v zóně. Zóny definuje RFC 4007. Problém
nejednoznačnosti může nastat v situaci na obr. 02-20.
Linka B
Linka A
Zóna ID %8
Zóna ID %12
Zóna ID %6
Linka C
Obr. 02-20 Problematika více rozhraní v jednom uzlu
Jedná se například o počítač, který obsahuje více síťových rozhraní. Příkladem takovéhoto
počítače může být směrovač realizovaný pomocí programu Quagga, komunikační server,
tiskový server nebo sensor server. Potom tyto servery poskytují službu uživatelům v podsíti
A a na linkách B a C jsou připojeny modemy, tiskárny nebo sensory.
Jednotlivým rozhraním jsou přiřazeny, krom dalších, adresy:



::1, lokální smyčka, unikátní adresa na rozhraní
ff01::1, všechny uzly na rozhraní, unikátní adresa na rozhraní
ff02::1, všechny uzly na lince, unikátní adresa na lince
V rámci unicast adres je nutno připustit možnost stejných lokálních linkových adres v každé
lince, například fe80::123.
32
V rámci testování je možno zadat z klávesnice příkaz „ping6 ::1“ nebo „ping6 fe80::123“.
Tímto vzniká problém, na které rozhraní bude paket směřovat či kterou linku má uživatel na
mysli. Zadání adresy v příkazu není jednoznačné, ale příkaz se vykoná, protože se aplikuje se
defaultní nastavení. Problém řeší definice zón. Zóna odpovídá dosahu a označuje číslem
s prefixem %, například zápis %6 označuje zónu 6. V našem případě je číslo zóny přiřazeno
rozhraní a zóna odděluje rozhraní od klávesnice, monitoru a uživatele. Hranice zóny v uzlu
obsahuje rozhraní a mimo zónu zůstává zbytek uzly. V rámci jednoho uzlu může být propojeno více zón. Příkladem takovéhoto uzlu je směrovač.
Proto příkaz „ping6 ::1%12“ jednoznačně identifikuje interfejs, který je dotazován. Obdobně
příkaz „ping6 ff02::1%6“ jednoznačně identifikuje linku C a paket bude doručen všem uzlům
na lince C.
Poznámka
Jde vůbec aplikovat příkaz ping6 ff02::1. Kdo odpoví, všechny uzly? Nutno prověřit.
Zóny různých dosahů se odvozují podle následujících pravidel, RFC 4007:

Každé rozhraní v uzlu přináleží do jedné zóny s dosahem lokální dosah rozhraní, toto platí pouze pro multicast adresaci.

Každá linka a každé rozhraní připojené do této linky přináleží do jedné zóny
s lokálním linkovým dosahem. Typické řešení je jedno rozhraní do jedné linky. Ale
definice umožnuje klidně dvě rozhraní na jednom uzlu připojit do jedné linky. Toto
platí pro obě adresace, unicast a multicast. Čili na různých linkách mohou být stejné
adresy unicast i multicast.

Existuje jedna zóna globálního dosahu obsahující všechny linky a síťová rozhraní
v Internetu. Platí pro oba způsoby adresování, unicast i multicast.

Hranice jiných zón, než dosahu linky, rozhraní globálního dosahu, musí být definované správcem sítě. Toto odpovídá definici vyšších dosahů, které také definuje
správce sítě.
Zóny mají následující vlastnosti, RFC 4007:

Hranice zón procházejí uzly nikoliv linkami. Pouze globální zóna nemá hranice. Hranice zóny rozhraní zahrnuje právě toto jedno síťové rozhraní.

Zóny stejného dosahu se nemohou překrývat, to značí, že nemají společné linky ani
rozhraní.

Zóny daného dosahu, který je menší než globální, jsou kompletně pokryty zónami
vyššího dosahu. Ta značí, že menší zóna má společné nějaké rozhraní a linky s nadřízenou zónou.

Pakety mohou být vyslané z jednoho rozhraní do jiného rozhraní ve stejné zóně.
Pakety nesmí opustit zónu. Aplikace tunelu …
33
Aplikace zón se týká lokálních unicast adres a multicast adres. Mezi lokální unicast adresy
patří lokální smyčka s adresou ::1, linková adresa s prefixem fe80::/10 a unikátní lokální
adresa s prefixem fc00::/7. Na různých linkách mohou být tyto adresy stejné. Pro globální
unicast adresy zóny nemají význam, protože jsou unikátní v celém Internetu. Multicast
adresy v jednotlivých dosazích mohou být také stejné. Potom je důležitá aplikace zón.
Jednotlivé zóny označujeme identifikátory zóny, zone_id, který je přiřazen rozhraní. Identifikátor zón je přiřazen uzlem nikoliv sítí. Proto, dvě rozhraní a více, které jsou připojené do
jedné zóny, mají různý identifikátor. Identifikátor zóny je jednoznačný v rámci uzlu nikoliv
v zóně. Identifikátor zóny je záležitost uzlu nikoliv sítě. Uživatel neboli uzel musí rozhodnout, na které rozhraní bude paket s lokální unicast adresou nebo multicast adresou zaslán.
Globální adresy se řídí směrovací tabulkou uzlu.
IPv6 adresa % Identifikátor zóny
Kanonická forma adresy
Povinný znak
Identifikátor
zóny je přiřazen
rozhraní nikoliv
zóně□
Nezáporné číslo
nebo
název interfejsu
Obr. 02-21 Způsob zápisu zónového identifikátoru s adresou
Identifikátor zóny se zapisuje za IPV6 adresu a je oddělený znakem %, obr. 02-21.
IPv6_addr%zone_id□
Samotná adresa IP verze 6 se zapisuje v kanonické formě. Identifikátor je číslo nebo
název interfejsu. Číselný identifikátor a název interfejsu přiřazuje uzel podle vlastních pravidel. Číselný identifikátor je nezáporné číslo a známé názvy interfejsu jsou eth0,
eth1, virt01 atd. Je definován defaultní číselný identifikátor zóny s hodnotou 0, který je
přiřazen rozhraní. Tento identifikátor se nemusí v zápisu uvádět. V důsledku čehož všechny
adresy bez identifikátoru zóny jsou automaticky předány na defaultní rozhraní.
Poznámka k aplikaci zónového identifikátoru
Operační systém Windows používá číselné označení zónové identifikátoru, který je přiřazen k rozhraní. Výpis příkazu ipconfig /all.
Operační systém Ubuntu používá jmenné identifikátory zóny. Jsou to přímo názvy linkových rozhraní. Výpis příkazu ip link show.
Možné zápisy cílové adresy s odpovídající zónou jsou ilustrovány na následujících příkladech:

fe80::123, jedná se o lokální linkovou adresu v linkové zóně 3 s dosahem 2 - linka, která je připojená na rozhraní eth0, které má zároveň číselný identifikátor
zóny 8.

ff02::2, jedná se skupinovou adresu všech směrovačů v linkové zóně „Vladimira“. Zóna je připojená k rozhraní eth6 s číselným identifikátorem zóny 1.
34

ff08::fb, jedná se o adresu všech multicast DNS serverů, RFC 6772, které jsou
umístěny v zóně „strom“ s dosahem 8 - organizace. Zóna je připojená k rozhraní
virt07 s číselným identifikátorem zóny 18.
Potom existují možné zápisy cílové adresy buď číselným identifikátorem zóny, nebo
se jmenným identifikátorem zóny:
fe80::123%8
ff02::2&1
ff08::fb%18
fe80::123%eth0
ff02::2%eth6
ff08::fb%virt07
2.10 Reference
[IANA_0201]
IPv6 Multicast Address Scopes; http://www.iana.org/assignments/ipv6multicast-addresses/ipv6-multicast-addresses.xhtml#ipv6-scope; on line
2014-11-21
[Internet_0201]IPv4 Address Report; http://www.potaroo.net/tools/ipv4/; on line 2014-1128
[Internet_0202]IPv6 Forum; http://www.ipv6forum.com/; on line 2014-11-28
[RFC_791]
INTERNET PROTOCOL; https://tools.ietf.org/html/rfc791; online 2014-11-21
[RFC_826]
An Ethernet Address Resolution Protocol -- or -- Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet
Hardware; http://tools.ietf.org/html/rfc826; online 2014-11-21
[RFC_1518]
An Architecture for IP Address Allocation with CIDR;
http://tools.ietf.org/html/rfc1518; on line 2014-11-21
[RFC_1883]
Internet Protocol, Version 6 (IPv6), Specification;
https://tools.ietf.org/html/rfc1883; online 2014-11-21
[RFC_3306]
Unicast-Prefix-based IPv6 Multicast Addresses;
[RFC_3307]
Allocation Guidelines for IPv6 Multicast Addresses;
[RFC_3849]
IPv6 Address Prefix Reserved for Documentation;
[RFC_3986]
Uniform Resource Identifier (URI): Generic Syntax;
[RFC_4007]
IPv6 Scoped Address Architecture; http://tools.ietf.org/html/rfc4007; on
line 2014-11-21
35
[RFC_4193]
Unique Local IPv6 Unicast Addresses; http://tools.ietf.org/html/rfc4193; on
line 2014-11-21
[RFC_4291]
IP Version 6 Addressing Architecture; http://tools.ietf.org/html/rfc4291; on
line 2014-11-21
[RFC_4489]
Link-Scoped IPv6 Multicast; http://tools.ietf.org/html/rfc4489; on line
2014-11-21
[RFC_4632]
Classless Inter-domain Routing (CIDR): The Internet Address Assignment
and Aggregation Plan; http://tools.ietf.org/html/rfc4632; on line 2014-1121
[RFC_4941]
Privacy Extensions for Stateless Address Autoconfiguration in IPv6;
https://tools.ietf.org/html/rfc4941; on line 2014-11-21
[RFC_5952]
A Recommendation for IPv6 Address Text Representation;
[RFC_7136]
IPv6 IID Significance; https://tools.ietf.org/html/rfc7136; on line 2014-11-21
[RFC_7346]
IPv6 Multicast Address Scopes; https://tools.ietf.org/html/rfc7346; on line
2014-11-21
[Satrapa_2011] Pavel Satrapa: Internetový protokol verze 6; cz.nic 2011; ISBN 978-80904248-4-5;
http://knihy.nic.cz/files/nic/edice/pavel_satrapa_ipv6_2012.pdf; on line
2014-11-20
[TCPIP_guide] The TCP/IP Guide; http://www.tcpipguide.com/free/index.htm; on line
2014-11-28
[wiki_0201]
IPv6; http://en.wikipedia.org/wiki/IPv6; online 2014-10-21
[wiki_0202]
End-to-end principle; http://en.wikipedia.org/wiki/End-to-end_principle; on
line 2014-10-21
[wiki_0203]
IPv4 address exhaustion;
http://en.wikipedia.org/wiki/IPv4_address_exhaustion; on line 2014-11-01
[wiki_0204]
Unicast; http://en.wikipedia.org/wiki/Unicast; on line 2014-11-01
[wiki_0205]
Anycast; http://en.wikipedia.org/wiki/Anycast; on line 2014-11-01
[wiki_0206]
Multicast; http://en.wikipedia.org/wiki/Multicast; on line 2014-11-01
[wiki_0207]
Classless Inter-Domain Routing;
http://en.wikipedia.org/wiki/Classless_InterDomain_Routing#CIDR_notation; on line 2014-12-01
36
[wiki_0208]
MAC address; http://en.wikipedia.org/wiki/MAC_address; on line 2014-1101
[wiki_0209]
Host (network); http://en.wikipedia.org/wiki/Host_(network); on line 201411-01
37
3 Auto-konfigurace
Dnes se požaduje, aby se zařízení konfigurovaly bez manuálního zásahu a následně mohly
mezi sebou spolupracovat. Tento princip se označuje auto-konfigurace a uplatňuje se nejen
v počítačích ale i v konfigurování počítačových sítí. V minulosti se adaptéry počítačů musely
manuálně konfigurovat pomocí přepínačů na modulu. Takovýto princip vyžadoval mnohdy
vynikající znalosti o funkci celého systému počítače, protože neodborné libovolné nastavení
vedlo k nefunkčnosti adaptéru či počítače, v nejhorším případě i k poškození. První snahy o
odstranění manuálního konfigurování lze vidět na sběrnici MicroChannel, která byla použita
v řadě osobních počítačů PS2 od společnosti IBM, [wiki_0303]. Známější princip je z oblasti
USB. Dnes totiž jakékoliv USB zařízení připojíme k počítači a automaticky se spustí konfigurace bez manuálního zásahu. V tomto případě se jedná o instalaci speciálních programů,
hlavně ovládačů do operačního systému. S tímto principem je spojován termín plug and
play, zastrč a používej.
S princip Plug and Play, zkratka PnP, je možné se dnes setkat na sběrnici personálních
počítačů PCI, Mini PCI, PCI Express, Mini PCI Express, rozhraní IEEE 1394 známé jako FireWire, karty do notebooku PCMCIA, PC Card a ExpressCard, známy interface USB, stav v roce
2013 podle [wiki_0303].
S technologií PnP úzce souvisí technologie hot pluggable (hot swap), [wiki_0305]. Ve zkratce, jedná se o technologii, která umožňuje instalovat hardwarové moduly do systému pod
napětím. Jedná se hlavně o elektrické specifikace, které musí zajistit nepřerušený chod
systému po elektrické stránce a zamezit zničení systému či zasouvajícího modulu. Nejznámější použití technologie hot swap je u USB a diskových polí. USB flash disk připojujeme
k notebooku pod napětím, disky v diskových polích je možné vyměňovat pod napětím.
Systémy se nemusejí vypínat.
Další pojem je Universal Plug and Play, zkratka UPnP, [wiki_0304]. UPnP je soubor protokolů, které dovolují síťovým zařízením jako je osobní počítač, tiskárny, Internetové brány, WiFi přístupové body a mobilní zařízení se navzájem vyhledávat v sítí, navázat spojení a síťové
služby pro sdílení dat, vzájemnou komunikaci. UPnP je primárně určen pro místní sítě, je
spravován UPnP fórem a dnes je 73-tí částí mezinárodního standardu ISO/IEC 29341.
Dnes existuje také soubor technik s názvem zeroconf, zero configuration - nulová konfigurace, [wiki_0301]. Jedná se o techniky, které automaticky vytvářejí použitelnou síť
s protokolem IP bez manuální intervence a specializovaných konfiguračních serverů. Výsledky se těchto snah se publikují jako RFC, což jsou základní dokumenty Internetu. Problematika zeroconf se zaměřuje na sítě od IP úrovně výše, aplikujeme 4. úrovňový model
Internetu. Ale s problematikou auto-konfigurace se setkáváme i na úrovni linkové, hlavně u
Ethernetu.
39
Technologie Ethernet je dnes dominující technologie linkové vrstvy pro vytváření drátových
sítí, jde o aplikaci Ethernetu a UTP nebo optického kabelu. Technologie Ethernet má za
sebou bouřlivý rozvoj nejen v oblasti přenosových kapacit, ale i na poli auto-konfigurace.
V této kapitole se zmíním o auto-negotiation (auto-vyjednávání) a PoE – Power over Ethernet (napájení přes Ethernet).
3.1 Zeroconf pro IP adresu
První problém na IP vrstvě Internet modelu je získávání IP adresy. Základem celosvětového
Internetu jsou veřejné IPv4 adresy. Jedná se přiřazení jedinečného čísla uzlu sítě, které je
celosvětově jedinečné. V protokolu IPv4 se pro tyto adresy používá termín veřejně IP adresy
a v nastupujícím protokolu IPv6 se používá termín globální IP adresy. Ale protokol IPv6
přinesl i nové principy v oblasti adres a s auto-konfigurací souvisejí adresy:



Oběžníkové adresy - Broadcast address, tyto adresy v protokolu IPv6 neexistují a
byly nahrazeny rezervovanými skupinovými adresami - multicast address a protokolem pro vyhledávání sousedů
Link-local address, lokální místní adresy, [wiki_0306], [wiki_0307]. Jedná se o blok
adres, který je daný prefixem fe80::/10, v praxi se častěji používá prefix fe80::/64.
Lokální místní adresa je jedinečná pouze na jedné lince. Uzel sítě může mít stejnou
lokální místní adresu, pokud je aplikována na různé linky. Jedná se o linkové adresy, které nesmí projít směrovačem - router, nejsou směrovatelné. Zbývajících 64 bitů je identifikátor interfejsu, který může být stanoven několika způsoby, nejen pro
linkovou ale i globální adresu:
 modifikovaný EUI-64 identifikátor, který lze automaticky vygenerovat
z MAC adresy interfejsu, RFC 4862,
 získán z DHCPv6 serveru,
 náhodně vygenerován a následná kontrola jedinečnost na lince, aplikace
protokolu NDP, RFC 4941,
 manuálně nastaven.
Reserved multicast address, rezervované skupinové adresy. Jedná se o blok rezervovaných adres daných prefixem ff00::/8, za kterým následuje identifikace skupiny.
Tyto adresy se vyznačují definicí dosahu, který vlastně určuje, až kam se tato adresa
může šířit. Číslo skupiny centrálně přiřazuje IANA a odpovídá uzlům, serverům a
službám v sítí.
Na základě lokálních místních v IPv6 vznikly lokální místní adresy v IPv4, RFC 3927,
[wiki_0307]. Lokální místní adresy v IPv4 jsou definované blokem v rozsahu od 169.254.1.0
do 169.254.254. 255. RFC 3927 definuje rozsah lokálních místních adres jako 169.254/16 ale
s podmínkou, že prvních 256 a posledních 256 adres je rezervováno pro budoucí použití,
které dnes nesmí být použity. Lokální místní IPv4 adresa může být přiřazena uzlu pouze,
když uzel nezískal IPv4 adresu jinými principy. Zde se myslí hlavně IPv4 adresu z DHCP
serveru popřípadě manuální nastavení.
40
Základní vlastnost lokálních místních adres je, že platí pouze na lince a nesmí ji opustit.
Router nesmí směrovat lokální místní adresy. Definice lokálních místních adres umožňuje
automatické přiřazení IP adres interfejsům.
Auto-konfigurace IP adres se chápe automatické přiřazení lokálních místních adres interfejsům v sítí. Tato auto-konfigurace se nazývá bezstavová konfigurace sítě, stateless configuration. Naproti tomu existuje stavová konfigurace, statefull configuration, dnes se jedná o
konfiguraci založenou na DHCP serverech popřípadě manuální konfigurace.
3.2 Auto-konfigurace IPv4 adres
Auto-konfigurace pro IPv4 lze pouze vykonat, pokud není dostupný jiný princip konfigurace
sítě. Jedná se o stavovou konfiguraci, mezi které patří hlavně konfigurace pomocí DHCP
serveru a manuální konfigurace. Základní kroky automatické konfigurace v síti IPv4 jsou:



Po uvedení do provozu klient vygeneruje zprávu DHCP Discovery a hledá DHCP server. Pokud v sítí existuje jeden či více DHCP serverů, potom oni odpovídají zprávou
DHCP Offer. V tomto případě se pokračuje stavovou konfiguraci uzlu a linková místní adresa se nepřiřazuje. V opačném případě, pokud uzel neobdrží nabídku z DHCP
serveru, přechází uzel do bezstavové konfigurace uzlu.
Klient si potom vygeneruje náhodné číslo, které použije pro vytvoření lokální místní
IPv4 adresy v rozsahu od 169.254.1.0 do 169.254.254.255. Algoritmus pro náhodné
číslo je doporučený. Klient si sám sobě přiřadil lokální místní IPv4 adresu.
Klient je povinen zkontrolovat jedinečnost přidělení IPv4 adresy na lince. Toto provede pomocí ARP protokolu. Adresa musí být jedinečná. Uzel je teď připraven komunikovat se svými sousedy na lince.
Pokud později host získá globální směrovatelnou nebo privátní IPv4 adresu, měl by upřednostňovat jejich používání. Ale používání prvně přiřazené lokální místní IPv4 adresy je stále
možné.
Společnost Microsoft používá pro tuto auto konfiguraci IPv4 adres pojem APIPA - Automatic
Private IP Addressing nebo kratší pojem auto-IP. Nutno si uvědomit, že přidělení lokální
místní adresy je dostatečné pro činnost Windows sítě v rámci pracovní skupiny. Aplikace
NetBIOS nad TC/IP, sítě SMB nebo CIFS, společnost Microsoft a Windows for Workgroup,
teorie sdílení adresářů a tiskáren. Detailnější informace o auto konfiguraci IPv4 sítě lze najít
v [wiki_0307], [MS_0301] a [MS_0302].
3.3 Adresy uzlu
Nutno si uvědomit, že jedno rozhraní uzlu může mít libovolný počet IP adres. V IP protokolu
verze ž se definují povinné adresy, které musí být přiřazeny. RFC 4291 definuje následující
adresy, které musí být přiřazeny hostu:



Lokální linková adresa pro každé rozhraní
Všechny unicast a anycast adresy, které mu byly přiděleny rozhraní uzlu a to manuálně nebo automaticky
Adresa lokální smyčky, typicky se přiřazuje virtuálnímu rozhraní
41



Všechny skupinové adresy pro všechny rozhraní a linky
Skupinová adresa pro vyzývaný uzel - Solicited-Node Multicast Address, pro každou
unicast a anycast adresu uzlu
Skupinové adresy všech ostatních skupin, do kterých uzel patří
Poznámka k hostu
Hostem se chápe uzel sítě, který poskytuje informace, služby a aplikace uživatelům nebo
ostatním uzlům v sítí, [wiki_0309]. Typický host je server, klientský počítač. Naproti tomu
hostem není směrovač, mode, tiskárna apod.
anycast adresy
Skupinová adresa
uzlů s dosahem
rozhraní
Skupinová adresa
uzlů s dosahem linka
vyzývaný uzel
fe80::ec67:4f8:37ce:995a
2001:db8:123:abc:ec67:4f8:37ce:995a
2001:db8:123:789:ec67:4f8:37ce:995a
ff01::1
Přidělené adresy
k rozhraní na hostovi
ff02::1
ff02::1:ffce:995a
ff15::ac04
Obr. 03-08 ukázka přidělených IPv6 adres rozhraní na hostu
Ukázkový příklad přiřazení IPv6 adres pro jedno rozhraní hosta je na obr. 03-08. Nutno
podotknout, že adresa není odvozena od fyzické MAC adresy rozhraní
3.4 Dosah adres
Je to nový pojem, který je definován u IP protokolu verze 6 a souvisí s multicast adresami.
Dosah definuje rozsah sítě, ve kterém se adresa může šířit a je unikátní. Pokud cílová adresa Dosah - scope□
v paketu má dosah, potom směrovače nesmí připustit šíření paketu mimo tento dosah.
Dosahy je definován RFC 4291 a RFC 7346 následně:


Dosah 1, rozhraní, lokální smyčka - Interface-Local scope. Je to nejmenší dosah, kteDosah 1□
rý vlastně neopouští síťový adaptér. Uzel sítě, jako celek, není součástí dosahu rozhraní, ale pouze adaptér je součásti dosahu. Pokud uzel má více síťových adaptérů,
potom má stejný počet dosahů velikosti rozhraní.
Dosah 2, lokální linkový dosah - Link-Local scope. Linka se zde chápe jako podsíť.
□
Linka se tím pádem vyznačuje směrovacím prefixem. Jinak, aplikace přepínačů ne- Dosah 2
vytváří linky, protože přepínač pracuje s fyzickými adresami rozhraní, to je linkové
vrstvě TCP/IP modelu.
42







Dosah 3 – lokální oblastní dosah – Realm local scope. Tento dosah se odvozuje od
konkrétní sítě a je předpokládáno, že se bude týkat technologii „ IPv6 over foo“.
Přesný rozsah tohoto dosahu má být specifikován příslušným RFC a registrován u
IANA. Tento dosah je specifikován teprve od roku 2014, RFC 7346. Původně tento
dosah byl podle RFC 4291 rezervován.
Dosah 4 – lokální administrátorský dosah - Admin-Local scope. Jedná se o nejmenší
dosah, který musí být manuálně konfigurován. Tento dosah nejde automaticky odvodit z fyzické topologie či dalších informací o sítí.
Dosah 5 – lokální dosah místa - Site-Local scope. Jedná se o dosah, který pokrývá
jedno místo. Jak je vidět, tento dosah je volně definován a proto hranice definuje
správce sítě při zohlednění dosahu organizace.
Dosah 8 – lokální dosah organizace - Organization-Local scope. Jedná se o dosah
pokrývající více míst., které patří jedné organizaci.
Dosah E – globální dosah - Global scope. Jedná se od dosah pokrývající celý Internet.
Rezervované dosahy 0 a F – reserved. Podléhají IANA.
Nepřiřazené dosahy 6, 7, 9, A, B, C, D – unassigned. Tyto dosahy jsou dostupné pro
administrátory, aby definovali dodatečné multicast regiony. Je předpokládáno, že
rozsah sítě se vzrůstajícím dosah se bude zvětšovat, popřípadě zůstane stejný, nikoliv menší.
 Dosah A, pokrývající národní síť. Tento dosah je definován pro evropské národní akademické sít2. Dosah A v síti CESNET2 pokrývá celou tuto národní
síť, [Satrapa_2011].
Definice hranic jednotlivých dosahů se stanovují podle RFC 7346 jednak podle fyzického
propojení nebo podle administrátorského členění. Administrátorské hranice vlastně definuje správce sítě nebo v zastoupení poskytovatel Internetu. Nejnižší dosahy se odvozují od
fyzického propojení sítě nebo od jiných konfigurací, které se nevztahují k multicast adresaci.
Jedná se o dosahy lokálního rozhraní (1), lokální linky (2), lokální oblast (3). Výší dosahy jsou
odvozeny od administrátorského členění s tím, že globální dosah (E) nemá hranice. Jedná se
o dosahy lokální administrátorský dosah (4), lokální místo (5) a lokální organizace (8).
Ukázka dosahů v sítí je na obr. 02-19. Dosah a rozhraní a linka je dán topologii sítě. Oblastní
dosah není zakreslen, protože souvisí s hlavně s principem „IPv6 over“ a je dán RFC. Vyšší
dosahy od 4 – administrátorský jsou již definovány správce sítě a vlastně závisí na jeho
rozhodnutí. Základním požadavkem však je, aby byla dodržena vzestupnost dosahů, popřípadě stejnost.
V naší ukázkové síti lze vést hodně polemik, protože ne vždy známe konkrétní zapojení
nadřízené sítě. V případě malé organizace či soukromého připojení lze pouze jednoznačně
definovat rozhraní a linku, kdy hranice jsou dány fyzickým propojením. Na obrázku se jedná
o linku A. Linkový dosah by mohl být i administrátorský dosah, což je přirozené, protože
každá takováto malá síť by měla mít správce. Definice vyšších dosahů by již závisela na vyšší
topologii propojení a poskytovateli Internetu. Jako správce malé sítě nemusím o tom hodně
vědět ani mít možnost rozhodovat.
43
Dosah 3□
Dosah 4□
Dosah 5□
Dosah 8□
Dosah E□
Další zajímavou polemiku lze vést o místech A, B a C a definici administrátorského dosahu.
Definice místa je volná a závisí na správci sítě, který by měl vzít v úvahu, zda se bude definovat dosah organizace. Je předpoklad, že na v rámci místa budou aplikovány unikátní
lokální IPv6 unicast adresy. Na obrázku jsou zakreslena místa B a C, jako samostatné zóny.
Nic nebrání jejich sloučení do jednoho místa, vše závisí od správce. Zůstává administrátorský dosah, který není zakreslen. Zde by se spíše hodilo ztotožnění administrátorského
dosahu s místem.
Dosah organizace se skládá z více míst. Definice nic neříká o jejich propojení ani o geografickém rozmístění. Dá se předpokládat, že dosah organizace budou využívat velké společnosti či poskytovatel Internetu. Organizace již zajištuje propojení míst buď vlastními linkami,
nebo veřejným Internetem. Opět, dosah organizace definuje správce. Opět se dá předpokládat aplikace unikátních lokálních IPv6 unicast adres, které dokážou propojit jednotlivé
místa v rámci organizace.
3.5 Auto-konfigurace IPv6 adres
Postup přidělování IPv6 adres je jiný v porovnání IPv4. Nutno vzít v úvahu dobu vzniků obou
protokolů a zkušenosti s používáním. Bezestavová auto konfigurace v prostředí IPv6 využívá
definice lokálních místních adres, multicastových adres s definovaným dosahem, Neighbor
Discovery Protocol – NDP a v neposlední řadě schopnosti interfejsu automaticky generovat
identifikátor interfejsu a to buď jako modifikovaný EUI-64 (nebo náhodné číslo prověřit).
Nutno se také zmínit, že jeden interfejs v sítí IPv6 může mít přiřazeno IPv6 adres kolik chce,
počet přiřazených IPv6 adres a ani typy není specifikován. Každému interfejsu, který je
připojen do IPv6 sítě se přiřazuje lokální místní adresa IPv6.
Základní kroky pro automatické konfigurace v IPv6 podle RFC 2462 a[tcpipguid_01] jsou:






Vygenerování lokální místní adresy. Prefix je fe80::/8, identifikátor interfejsu je generován jako modifikovaný EUI-64 identifikátor nebo náhodné číslo.
Test jedinečnosti vygenerované lokální místní adresy. Pro test se použije NDP protokol, který je součástí ICMPv6 protokolu. Interfejs vyšle zprávu Neighbor Solicitation a pokud dostane odpověď Neighbor Advertisement to značí, že IPv6 adresa je
použita na lince. Uzel vygeneruje novou adresu a provede opět kontrolu.
Test výjimečnosti je úspěšný a interfejs může používat ověřenou lokální místní adresu. Upozornění, lokální místní adresa není směrovatelná a nesmí opustit linku.
Kontaktování místního routru. Pro získání globálního prefixu se kontaktuje router.
Uzel čeká na zprávu Router Advertisement, která je v pravidelných intervalech vysílaná routrem nebo vygeneruje Router Solicitation. Odpověď je Router Advertisement. Zprávy pocházejí z NDP protokolu.
Host přijme Router Advertisement, prvně na základě této zprávy rozhodne o dalším
způsobu konfigurace. Pokud je jeden z příznaků M nebo O nastaven, potom se přechází na stavovou konfiguraci.
Vytvoření globální IPv6 adresy, zpráva Router Advertisement obsahuje směrovací
prefix či prefixy. Host na jejich základě sestaví globální IPv6 adresu či adresy. Jako
identifikátor interfejsu se použije identifikátor z lokální místní adresy. Upozorňuji,
44
Unique Local
IPv6 Unicast
Addresses,
prefix fc00/7□
že směrovací prefixy jsou časově omezené a v čase se mění, problematika přečíslování IPv6.
Automatická konfigurace zajišťuje omezené možnosti konfigurování uzlu sítě, minimálně
tak, aby uzel byl schopen komunikovat v rámci lokální linky.
3.6 Reference
[MS_0301]
Description of Automatic Private IP Addressing in Windows Millennium
Edition; http://support.microsoft.com/kb/307287/cs
[MS_0302]
Windows 7 and Network Connectivity; http://technet.microsoft.com/cscz/itmanagement/ff765029
[RFC_791]
INTERNET PROTOCOL; https://tools.ietf.org/html/rfc791; online 2014-11-21
[RFC_826]
An Ethernet Address Resolution Protocol -- or -- Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet
Hardware; http://tools.ietf.org/html/rfc826; online 2014-11-21
[RFC_1518]
An Architecture for IP Address Allocation with CIDR;
[RFC_1883]
Internet Protocol, Version 6 (IPv6), Specification;
[RFC_3306]
Unicast-Prefix-based IPv6 Multicast Addresses;
[RFC_3307]
Allocation Guidelines for IPv6 Multicast Addresses;
[RFC_3849]
IPv6 Address Prefix Reserved for Documentation;
[RFC_3986]
Uniform Resource Identifier (URI): Generic Syntax;
[RFC_4007]
IPv6 Scoped Address Architecture; http://tools.ietf.org/html/rfc4007; on
line 2014-11-21
[RFC_4193]
Unique Local IPv6 Unicast Addresses; http://tools.ietf.org/html/rfc4193; on
line 2014-11-21
[RFC_4291]
IP Version 6 Addressing Architecture; http://tools.ietf.org/html/rfc4291; on
line 2014-11-21
[RFC_4489]
Link-Scoped IPv6 Multicast; http://tools.ietf.org/html/rfc4489; on line
2014-11-21
45
[RFC_4632]
Classless Inter-domain Routing (CIDR): The Internet Address Assignment
and Aggregation Plan; http://tools.ietf.org/html/rfc4632; on line 2014-1121
[RFC_4941]
[RFC_5952]
A Recommendation for IPv6 Address Text Representation;
[RFC_7136]
IPv6 IID Significance; https://tools.ietf.org/html/rfc7136; on line 2014-11-21
[RFC_7346]
IPv6 Multicast Address Scopes; https://tools.ietf.org/html/rfc7346; on line
2014-11-21
[RFC 2462]
IPv6 Stateless Address Autoconfiguration;
http://tools.ietf.org/html/rfc2462 ; on line 2014-01-10
[RFC 3927]
Dynamic Configuration of IPv4 Link-Local Addresses;
http://tools.ietf.org/html/rfc3927
[RFC 4862]
IPv6 Stateless Address Autoconfiguration;
[RFC 4291]
IPv6 Addressing Architecture; http://tools.ietf.org/html/rfc4291
[RFC 4941]
[wiki_0301]
Zeroconf; http://en.wikipedia.org/wiki/Zeroconf; březen 2013
[wiki_0302]
Autoconfiguration; http://en.wikipedia.org/wiki/Autoconfiguration; březen
2013
[wiki_0303]
Plug_and_play; http://en.wikipedia.org/wiki/Plug_and_play; březen 2013
[wiki_0304]
Universal_Plug_and_Play;
http://en.wikipedia.org/wiki/Universal_Plug_and_Play; březen 2013
[wiki_0305]
Hot_swap; http://en.wikipedia.org/wiki/Hot_swap; březen 2013
[wiki_0306]
IPv6_address; http://en.wikipedia.org/wiki/IPv6_address; březen 2013
[wiki_0307]
Link-local_address; http://en.wikipedia.org/wiki/Link-local_address; březen
2013
[tcpipguid_01] IPv6 Autoconfigurationand Renumbering ;
http://www.tcpipguide.com/free/
t_IPv6AutoconfigurationandRenumbering.htm; březen 2013
46
4 Quagga
Směrování je proces, při němž směrovač přijme paket a na základě směrovací tabulky
rozhodne o jeho dalším odeslání, či neodeslání. V případě, že příchozí paket je ze stejného
rozhraní, kde má být odeslán, je paket zahozen. V případě, že směrovač na základě směrovací tabulky nenajde odchozí cestu, měl by odeslat informaci o nedoručení daného paketu
[Malhotra_2002].
Pro efektivní směrování je proto velmi důležitá směrovací tabulka. Tato tabulka obsahuje
informace, které jsou nutné při rozhodování o směrování. Jednotlivé řádky směrovací
tabulky odpovídají jednotlivým směrovacím informacím. Tyto směrovací záznamy se mohou
objevit ve směrovací tabulce bud' na základě nastavení lokálního rozhraní, nebo pomocí
statických záznamů, nebo na základě dynamických směrovacích protokolů [Ashraf_2013].
4.1 Popis a konfigurace open source projektu Quagga
V této kapitole se seznámíme s open source projektem Quagga. Tento projekt podporuje
statické i dynamické směrování pro protokoly IPv4 a IPv6. Nastavení IP adres a statické
směrování se nastavuje v modulu zebra. Podporuje dynamické směrování protokolů RIP,
RIPng, OSPF, OSPFv3, BGP a ISIS. Jednotlivé protokoly jsou podporovány pomocí samostatných modulů [Quagga_2013].
Nejdříve nainstalujeme software Quagga. Ten můžeme naistalovat bud' ze zdrojových
souborů, nebo jednodušeji pomocí instalačních nástrojů příslušné linuxové distribuce.
Pokud budeme používat Debian, nebo podobné distribuce využijeme následující příkaz pro
instalaci balíčku.
Linux#apt-get install quagga
Následně musíme aktivovat příslušné moduly (démony), minimálně modul zebra, případně
další moduly, pokud chceme využít i dynamické směrování. Následuje výpis, kde je povolen
modul zebra a modul ospfd.
Linux#vim /etc/quagga/deamons
zebra=yes
bgpd=no
ospfd=yes
ospf6d=yes
47
V dalším kroku musíme připravit konfigurační soubory pro jednotlivé moduly. Tyto konfigurační soubory můžeme zkopírovat a následně upravit. Také nesmíme zapomenout nastavit
přístupová práva a vlastnictví k jednotlivým konfiguračním souborům. Při každé změně
konfiguračních souborů musíme restartovat Quaggu.
Linux#cp /usr/.../examples/zebra.conf.sample
/etc/quagga/zebra.conf
Linux#cp /usr/.../examples/ospfd.conf.sample
/etc/quagga/ospfd.conf
Linux#cp /usr/.../examples/ospf6d.conf.sample
/etc/quagga/ospf6d.conf
Linux#chown quagga.quaggavty /etc/quagga/*.conf
Linux#chmod 640 /etc/quagga/*.conf
Linux#/etc/init.d/quagga restart
Jednotlivé moduly jsou spuštěny a lze se k nim připojovat jako k jakékoliv aplikaci spuštěné
na počítači. Například příkazem nmap můžeme zjistit otevřené porty a tím i spuštěné moduly. Následuje přístup k modulu zebra, ospfd a modulu ospf6d.
Linux#telnet localhost 2601
Linux#telnet localhost 2604
Linux#telnet ::1 2606
Nakonec nesmíme zapomenout povolit v Linuxu přeposílání paketů mezi jednotlivými
rozhraními. Musíme nastavit přeposílání paketů pro IPv4 a IPv6 protokoly.
Linux#echo 1 > /proc/sys/net/ipv4/ip_forward
Linux#echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
4.2 Směrovací tabulka
Směrovací tabulka je speciálně navržená datová struktura v operační paměti směrovače
nebo počítače sloužící k uchování dat o jednotlivých cestách a pro směrování datagramu v
sítí. Směrovací informace jsou v tabulce členěny do řádků, kde každý řádek obsahuje informaci o jedné cestě. Směrovací tabulka tak do jisté míry obsahuje informace o topologii sítě.
Na základě znalosti topologie může směrovač nebo počítač rozhodnout co bude provedeno
s přijatým nebo odesílaným datagramem. Současné operační systémy mají směrovací
tabulku implementovánu jako součást jádra, tzv. TCP/IP stack.
V operačním systému UNIX/Linux je možné vypsat směrovací tabulku vypsat příkazem route
-n nebo příkazem ip route show.
root@debian:~# route -n
48
Směrovací tabulka v jádru pro IP
Adresát Brána Maska Přízn Metrik Odkaz Užt Rozhraní
0.0.0.0 158.196.218.1 0.0.0.0 UG 0 0 0 eth0
158.196.104.0 0.0.0.0 255.255.252.0 U 9 0 0 wlan0
158.196.218.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
root@debian:~# ip route show
default via 158.196.218.1 dev eth0 proto static
158.196.104.0/22 dev wlan0
158.196.105.36 metric 9
158.196.218.0/24 dev eth0
158.196.218.68 metric 1
proto
proto
kernel
scope
link
src
kernel
scope
link
src
4.3 Statické směrování
Při statickém směrování je nutno jednotlivé záznamy vkládat ručně (staticky). Je nutné si
uvědomit, že musíme vkládat ty sítě, nebo části sítí, které daný směrovač nezná. Musíme
také stanovit, kterým rozhraním směrovače povede cesta a na jakou vzdálenou adresu
musíme příslušný paket přeposlat.
Výhodou statického směrování je bezpečnost a neposílání žádných směrovacích informací.
Tím také šetříme přenosové kapacity. Bohužel nevýhodou statického směrování je nerespektování změn v topologii sítě. Pokud vytvoříme novou sít' je nutno tuto informaci nastavit ručně na všech směrovačích v síti.
Statické směrování se typicky používá na koncových stanicích, nebo ve směrovačích pokud
se jedná o malé sítě, kde nejsou požadavky na časté změny. Statické směrování také používají poskytovatelé internetových služeb ISP, jako záznam pro směrování k cílovým sítím,
typicky pro malé firmy a instituce.
4.3.1 Konfigurace a testování statického směrování IPv4 pomocí
Quagga
V této kapitole se blíže podíváme, jak nakonfigurovat statické směrování na linuxu při
použití projektu Quagga. Nejdříve musíme naistalovat baliček quagga. Následně musíme
povolit modul zebra, ve kterém potom budeme jednak nastavovat IPv4 adresy a jednak
statické směrování.
Nastavení IPv4 adres se nastavuje bud' přímo v konfiguračním souboru zebra, nebo pomocí
příkazů, které jsou velmi podobné Cisco příkazům. Následuje konfigurace jednotlivých
49
směrovačů. Nejdříve nastavíme jednotlivá rozhraní a přidělíme jim příslušné IPv4 adresy
podle obrázku 1.
Obr. 04-01 Statické směrování v IPv4
Konfigurace směrovače Quagga_A:
Quagga_A#configure terminal
Quagga_A(config)#interface eth0
Quagga_A(config-if)#ip address 11.0.0.1/24
Quagga_A(config-if)#link-detect
Quagga_A(config-if)#ip address 100.0.0.2/28
Quagga_A(config-if)#link-detect
Quagga_A(config)#ip route 100.0.0.0/28 100.0.0.1
Quagga_A(config)#ip route 10.0.0.0/24 100.0.0.1
Pokud bude všechno správně nakonfigurované, můžeme si nechat vypsat směrovací tabulky. Směrovací tabulky jednotlivých směrovačů by měly obsahovat všechny sítě, které jsou
dostupné. V našem případě se jedná celkem o čtyři sítě. Následuje výpis směrovací tabulky,
kterou můžeme vidět na směrovači Quagga_A.
Quagga_A#show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O
- OSPF,
I - ISIS, B - BGP, > - selected route, * - FIB route
C>* 11.0.0.0/24 is directly connected, eth0
C>* 100.0.0.0/28 is directly connected, eth1
S>* 100.0.0.16/28 [1/0] via 100.0.0.1, eth1
S>* 10.0.0.0/24 [1/0] via 100.0.0.1, eth1
50
4.3.2 Konfigurace a testování statického směrování IPv4 pomocí
Cisco CLI
V této kapitole si ukážeme jednoduchou konfiguraci síťových rozhraní a konfiguraci statického směrování na směrovači Cisco. Nejdříve nastavíme IPv4 adresy na jednotlivá rozhraní,
kde nesmíme zapomenout na aktivaci rozhraní. Poté můžeme přejít ke konfiguraci statického směrování. Při statickém směrování vždy zadáváme sítě, které neznáme.
Konfigurace směrovače Cisco_R:
Cisco_R#configure terminal
Cisco_R(config)#interface eth0
Cisco_R(config-if)#ip address 100.0.0.1 255.255.255.240
Cisco_R(config-if)#no shutdown
Cisco_R(config)#interface eth1
Cisco_R(config-if)#ip address 100.0.0.17 255.255.255.240
Cisco_R(config-if)#no shutdown
Cisco_R(config)#ip route 10.0.0.0 255.255.255.0 100.0.0.18
Cisco_R(config)#ip route 11.0.0.0 255.255.255.0 100.0.0.2
Pokud nakonfigurujeme jednotlivá rozhraní a nastavíme statické směrování, můžeme si
nechat vypsat směrovací tabulku na směrovači Cisco_R. Tato tabulka je trochu odlišná od
směrovače Quagga_A. Příslušný výpis je krácen.
Router_R#show ip route
Codes: C - connected, S - static, O - OSPF .... Gateway of
last resort is not set
100.0.0.0/16 is subnetted, 2 subnets C 100.0.0.0/28 is directly connected, Ethernet0
C 100.0.0.16/28 is directly connected, Ethernet1 10.0.0.0/8 is
subnetted, 1 subnets
S 10.0.0.0/24 [1/0] via 100.0.0.18 11.0.0.0/8 is subnetted, 1
subnets
S 11.0.0.0/24 [1/0] via 100.0.0.2
4.3.3 Statické směrování pro IPv6
Protože IPv4 adresy docházejí, dá se předpokládat velký zájem o směrování, založeném na
IPv6 protokolu. V této kapitole si ukážeme jednoduché nastavení IPv6 statického směrování. Zapojení je vidět na následujícím obrázku 2.
51
Obr. 04-02 Statické směrování v IPv6
Na rozhraních se nastaví IPv6 adresy a může se ještě zapnout podpora propagování IPv6
prefixu do vnitřní sítě, tzv. RA (Router Advertisement). Následně nastavíme statické směrování pro IPv6. Opět nastavujeme ty sítě, které nejsou na směrovači přímo připojené.
Quagga_A(config)#ipv6 address 2001:100:11::1/64
Quagga_A(config)#no ipv6 nd suppress-ra
Quagga_A(config)#ipv6 nd prefix-advertisement 2001:100:11::/64
Quagga_A(config)#ipv6 address 2001:100:100::2/64
Quagga_A(config)#ipv6 nd suppress-ra
Quagga_A(config)#ipv6 route 2001:100:160/64 2001:100:100:1
Quagga_A(config)#ipv6 route 2001:100:10/64 2001:100:100:1
Podpora posílání IPv6 prefixu je pouze na rozhraní směřující do vnitřní sítě na PC1. Podobným způsobem nastavíme i další směrovač. Následuje výpis směrovací tabulky pro IPv6.
Quagga_A#show ipv6 route
C>* 2001:100:11::/64 is diretly connected, eth0
C>* 2001:100:100::/64 is diretly connected, eth1
S>* 2001:100:160::/64 [1/0] via 2001:100:100::1, eth1
S>* 2001:100:10::/64 [1/0] via 2001:100:100::1, eth1
Nejdříve v globálním nastavení povolíme IPv6 směrování. Posléze, na jednotlivých rozhraních nastavíme IPv6 adresy a aktivujeme IPv6 protokol. Následuje základní nastavení pro
směrovač Cisco_R.
Cisco_R(config)#ipv6 unicast-routing
Cisco_R(config)#interface Ethernet 0
52
Cisco_R(config-if)#ipv6 address 2011:100:100::1/64
Cisco_R(config-if)#ipv6 enable
Cisco_R(config-if)#ipv6 route 2001:100:11::/64 2001:100:100:2
Cisco_R(config-if)#ipv6 route 2001:100:10::/64 2001:100:160:2
Pokud nakonfigurujeme jednotlivá rozhraní a nastavíme statické směrování, můžeme si
nechat vypsat směrovací tabulku na směrovači Cisco_R. Tato tabulka je trochu odlišná od
směrovače Quagga_A. Příslušný výpis je krácen.
Cisco_R#show ipv6 route
Codes: C - Connected, S - Static
C 2001:100:100::/64 [0/0] via Ethernet0, directly connected
S 2011:100:11::/64 [1/0] via 2001:100:100:2
S 2011:100:11::/64 [1/0] via 2001:100:100:2
4.4 Dynamické směrování pomocí protokolu OSPF
Při dynamickém směrování je nutno nejdříve zvolit vhodný směrovací protokol a ten je
nutno správně nakonfigurovat. Na rozdíl od statického směrování, budeme nyní nastavovat
ty sítě, které daný směrovač zná. Směrovací tabulka se bude tvořit průběžně, podle toho
jaké informace si budou jednotlivé směrovače vyměňovat. Výhodou dynamického směrování je jeho přizpůsobivost podle momentálního stavu sítě.
V této kapitole se blíže seznámíme se směrovacím protokolem OSPF (Open Shortest Path
First). Je to otevřený protokol, vhodný jak pro malé sítě, tak i pro relativně velké sítě.
Umožňuje rozdělovat velké sítě do tzv, oblastí (Area), ve kterých si směrovače vyměňují
potřebné informace, na základě kterých si každý směrovač vypočítá nejkratší cesty do
příslušných sítí. Tyto vypočítané informace se následně objeví ve směrovací tabulce.
OSPF směrovač je typickým představitel směrovacího protokolu typu Link State. Ve své
paměti si vytváří topologii sítě, kterou si ukládá do topologické databáze. Kromě toho si
také vytváří databázi sousedů, se kterými si vyměňuje potřebné informace. Z těchto získaných informací spouští algoritmus pro výpočet nejkratší cesty. Na základě těchto výpočtů se
naplňuje směrovací tabulka. Každý směrovací protokol potřebuje kritérium, podle kterého
posoudí, která z více možných cest je nejvýhodnější. Toto kritérium se nazývá metrika. OSPF
53
Protokol využívá jako metriku cenu (cost), nejčastěji tomu odpovídá šířka pásma daného
rozhraní. Tento parametr je možné na každém rozhraní nastavit. Čím lepší metrika, tím nižší
číslo. Každý směrovač pravidelně posílá tzv. Hello pakety, na základě kterých se snaží navázat sousedské vztahy s ostatními směrovači. Pokud se podaří navázat sousedský vztah se
sousedním směrovačem, mohou si tyto směrovače vyměnit své topologické databáze. Tyto
informace se přenášejí pomocí LSA (Link State Advertisement) paketů. Po naplnění topologické tabulky se spouští SPF algoritmus a výsledné informace se potom mohou objevit ve
směrovací tabulce [Malhotra_2002].
4.4.1 Konfigurace a testování dynamického směrování OSPF pro
IPv4
V této kapitole si ukážeme konfiguraci protokolu OSPF pomocí projektu Quagga. Nastavení
IPv4 adres na jednotlivých rozhraních je popsáno v kapitole pro statické směrování. Nyní
budeme nastavovat pouze OSPF protokol. Při dynamickém směrování zadáváme ty sítě,
které směrovač zná. Na následujícím obrázku 3 je schéma zapojení jednoduché sítě. Zde si
ověříme funkčnost dynamického směrování na zařízeních s nainstalovaným a nakonfigurovaným programem quagga. Abychom si ověřili spolupráci s jinými zařízeními, je zde použit
směrovač Cisco, řady 2801. Pro jednoduchost předpokládáme jednu oblast.
Obr. 04-03 Dynamické směrování OSPF v IPv4
Následuje nastavení základních parametrů protokolu OSPF na směrovači Quagga_A.
Quagga_A(config)#router ospf
Quagga_A(config-router)#network 100.0.0.0/28 area 0
Quagga_A(config-router)#network 11.0.0.0/24 area 0
Po nastavení příslušných sítí, si můžeme zobrazit směrovací tabulku. Funkčnost sítí nakonec
ověříme testem dostupnosti mezi jednotlivými cílovými počítači PC1 a PC2.
Quagga_A#show ip route ospf
Codes: K - kernel route, C - connected, S - static, R - RIP, O
- OSPF, I - ISIS, B - BGP, > - selected route, * - FIB route
O>* 100.0.0.16/28 [110/11] via 100.0.0.1, eth1
O>* 10.0.0.0/24 [110/22] via 100.0.0.1, eth1
54
4.4.2 Konfigurace a testování dynamického směrování OSPF pro
IPv6
V této kapitole si ukážeme nastavení a testování dynamického směrování OSPF v IPv6 sítích.
Budeme opět využívat stejné zapojení, jako při statickém směrování. Jednotlivé IPv6 adresy
a další informace jsou na obrázku 4.
Obr. 04-04 Dynamické směrování OSPF v IPv6
Následuje nastavení základních parametrů protokolu OSPF pro IPv6 na směrovači
Quagga_A. Na tomto směrovači jsou kromě IPv6 adresy nastaveny všechny parametry v
nastavení pro směrování.
Quagga_A(config)#router ospf6
Quagga_A(config-router)#router-id 1.1.1.2
Quagga_A(config-router)#interface eth2 area 0.0.0.0
Quagga_A(config-router)#interface eth4 area 0.0.0.0
Následuje zkrácený výpis směrovací tabulky na směrovači Quagga_A. Jednotlivé OSPF
informace byly získány pomocí local-link adres fe80::..
Quagga_A#show ipv6 route
C>* 2001:100:11::/64 is directly connected, eth0
C>* 2001:100:100::/64 is directly connected, eth1
O>* 2001:100:160::/64 [110/2] via fe80::21e:f7ff:feac:4a62,
eth1, 00:03:14
O>* 2001:100:10::/64 [110/3] via fe80::21e:f7ff:feac:4a62,
eth1, 00:03:14
Nejdříve v globálním nastavení povolíme IPv6 směrování. Posléze, na jednotlivých rozhraních nastavíme IPv6 adresy a aktivujeme IPv6 protokol. Na Cisco zařízeních se nastavuje
většina parametrů na rozhraních. V nastavení pro směrování stačí nastavit pouze parametr
router-id. Následuje základní nastavení pro směrovač Cisco_R.
55
Cisco_R(config)#ipv6 unicast-routing
Cisco_R(config-if)#ipv6 ospf 1 area 0
Cisco_R(config)#router ospf 1
Cisco_R(config-router)#router-id 1.1.1.1
OSPF směrovače si neustále vyměňují „Hello pakety“ jednak pro navázání komunikace a
také pro udržení komunikace. Při použití protokolu IPv6 je použita multicast adresa FF02::5.
Cisco_R#debug ipv6 ospf hello
OSPFv3: Send hello to FF02::5 area 0 on Ethernet0
OSPFv3: Send hello to FF02::5 area 0 on Ethernet1
OSPFv3: Rcv hello from 1.1.1.3 area 0 from Ethernet0
OSPFv3: Rcv hello from 1.1.1.2 area 0 from FastEthernet1
Na následujícím výpisu je zkrácená směrovací tabulka pro směrovač Cisco_R. Jednotlivé
informace o jiných sítích byly propagovány pomocí OSPF protokolu a tzv. local-link IPv6
adresy fe80::.
Cisco_R#sh ipv6 route
O 2001:100:10::/64 [110/2] via FE80::230:5FF:FE8E:5E4F, Ethernet1
O 2001:100:11::/64 [110/2] via FE80::230:5FF:FE8E:5E19, Ethernet0
Funkčnost sítě si můžeme ověřit testem dostupnosti mezi koncovými zařízeními.
PC1# ping6 2001:100:11::2
PING 2001:100:11::2(2001:100:11::2) 56 data bytes
64 bytes from 2001:100:11::2: icmp_seq=1 ttl=61 time=1.03 ms
64 bytes from 2001:100:11::2: icmp_seq=2 ttl=61 time=0.540 ms
--- 2001:100:11::2 ping statistics --56
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.540/0.786/1.032/0.246 ms
4.5 Reference
[Satrapa_2011] Pavel Satrapa: Internetový protokol verze 6; cz.nic 2011; ISBN 978-80904248-4-5; http://knihy.nic.cz/files/nic/edice/pavel_satrapa_
ipv6_2012.pdf; on line 2014-11-20
[Malhotra_2002]
Malhotra, R.: IP Routing, O'Reilly Media 2002
[Ashraf_2013] Ashraf, Z.: IPv6 Routing: A Practitioner Approach, LAP LAMBERT AcademicPublishing 2013
[Quagga_2013] Quagga; http://www.nongnu.org/quagga/; on line 2014-05-05
57
5 Jména a sítě
Pro správce sítě musí připustit, že všechna komunikace v Internetu je založena na adresách
souvisejících Internet protokolem – IP. Již v počátcích Internetu a protokolu verze 4 bylo
známo, že pro normální uživatele Internetu číselný kód IP adresy není vhodný
k zapamatování. Je to stejné jako s klasickým telefonním číslem, kdy uživatel si raději pamatuje jméno volajícího a příslušné číslo najde v různých seznamech, dříve klasický papírový
telefonní seznam, dnes adresářové služby v mobilních telefonech. Pro názvy uzlů sítě se
používají jména nebo doménové jména, které se překládají na IP adresy. Nejdříve si představíme systém jmen a doménových jmen a následně organizaci překladu, systém DNS.
S aplikací jmen úzce souvisí kódování znaků. V dalším textu je automaticky požíván Unicode
Unicode□
a formát UTF-8, pokud není uvedeno jinak.
Proto uzly počítačové sítě získávají jména a jejich tvar se liší v závislosti na sítí a dosahu
platnosti jmen. Zároveň existují i různé způsoby a organizace překladu jmen na IP adresy.
Při konfiguraci sítě se lze setkat s termíny jména, hostname, hosts, doménové jména,
FQDN. Je problematické definovat jednotlivé termíny, protože se vzájemně prolínají. Následně nelze definovat jednotnou syntax, protože vše závisí od kontextu a použití.
Hostname je jméno přiřazené uzlu sítě, pod kterým je uzel jednoznačně identifikován při
Hostname je unikomunikaci, [Internet_0501], [wiki_0501]. Hostname může být zápis, například:
kátní jméno použité
 andrea , jednoduché jméno, lze pouze předpokládat, že bude jednoznačné v rámci při komunikaci□
zlu, linky.

muj.pc.doma , princip jména, které je založeno na doménovém systému jmen. Při
dodržení určitých pravidel se dá předpokládat v celém Internetu.
Poznámky k hostname v Linuxu

Red Hat a Centos, HOSTNAME=<value>, kde <value> by mělo být FQDN, například
hostname.example.com , ale může to být cokoliv, když je to potřebné, [Cen-

tos_0501], [RedHat_0501] a [RedHat_0502].
Debian, nastavuje „system hostname“, ne FQDN, [Debian_0501]. □
FQDN – Full QualiFQDN - Full Qualified Domain Name je jméno, které jednoznačně identifikuje počítač nebo fied Domain Name□
uzel sítě v systému DNS. Zápis hostname vycházející z doménového principu DNS systému
59
je FQDN, například muj.pc.doma.local nebo muj.pc.doma.local. , [wiki_0502] a [Internet_0502]. Literatura se neshoduje na tečce na konci.
5.1 Linux a jména
Unix a Linux používá jména, která se uvádějí v různých konfiguračních souborech. Základem
je hostname , a jeho tvar je v každé distribuci jinak definován. Z poznámky vyplývá, že
Hostname má IP
hostname v Linuxu může být ve vhodném tvaru. Z různorodé definice se dá vymotat pouze adresu□
aplikací dosahu, v jakém dosahu je hostname unikátní a dá se použít k identifikaci uzlu v sítí.
Každému hostname je přiřazena IP adresa.
Další popis bude zaměřen pouze na distribuci Ubuntu desktop verze 14.04 aniž to bude dále
Ubuntu 14.04□
zdůrazňováno. Pro jiné distribuce je nutno dále uvedené informace ověřit.
Hostname se dá najít v označení některých oken, v promptu terminálu a jinde. Hostname
□
je dán konfiguračním souborem v /etc/hostname . Většinou se aplikuje se zde název ve /etc/hostname
tvaru jednoho jména bez domén, název, který neodpovídá FQDN. Hostname uvedené
v tomto souboru se také používá jako systemname .
Příkazy související s hostname


hostname , hostname -i, hostname novy_docasny
uname -u □
st@st-VirtualBox:~$ hostname
st-VirtualBox
st@st-VirtualBox:~$ cat /etc/hosts
127.0.0.1
localhost
127.0.1.1
st-VirtualBox
# The following lines are desirable for IPv6 capable hosts
::1
ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
st@st-VirtualBox:~$
Obr. 05-01 Výpis souboru /etc/hosts
Jménům přísluší IP adresy. Tím je dán princip, abychom nemuseli psát dlouhé IP adresy ale
□
jména, které si k nim přiřadíme. Vazbu mezi IP adresami a jmény obsahuje soubor /etc/hosts
/etc/hosts . Ukázka výpisu je na obr. 05-01. Z výpisu vyplývá:

Host má povolený protokol IPv4 a IPv6. IPv6 není plně konfigurován.
60

Hostname je st-VirtualBox a má přiřazenou IPv4 adresu 127.0.1.1 . IPv4 adresa
127/8 je loopback.

Doménovému jménu localhost je přiřazena IPv4 adresa 127.0.0.1 .

Jménům ip6-localhost a ip6-loopback je přiřazena IPv6 adresa ::1 .

IPv6 adresa fe00::0 , nový prefix, který je rezervován pro IEFT.?

IPv6 adresa ff00::0 , RFC4291 ji pokládá za rezervovanou multicast adresu.?

Multicast adresu pro všechny uzly v dosahu rozhraní a linky, ff01::1 a ff02::1 .

Multicast adresu pro směrovače v dosahu linky, ff02::2 .
Uvedený soubor vlastně slouží k statickému překladu jmen na IP adresu. Tento soubor se dá /etc/hosts
využít k zadání dalších vlastních adres a jejich jmen.
– statický překlad□
Výše uvedené soubory popisuji pouze vlastnosti ohledně hostname a dalších jmen - hosts,
které jsou spojeny se samotným hostem. Ale Internet používá DNS, který také překládá
jména na IP adresy. Proto je další konfigurační soubor, který usměrňuje pořadí překladu pro
resolver. Jedná so konfigurační soubor /etc/host.conf , obr. 05-02. Význam jednotlivých
/etc/host.conf□
položek je:

order host,bind , řádek definuje resolveru pořadí pro překlad jmen, nejdříve se použije soubor hosts a potom dynamický překlad pomocí se serverem nameserver .

multi on , tato volba umožňuje, aby hostiteli bylo v souboru /etc/hosts přiřazeno
více IP adres, jedná se o princip multihomed systémů.
student@student:~$ cat /etc/host.conf
# The "order" line is only used by old versions of the C library.
order hosts,bind
multi on
student@student:~$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf
#
DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 2001:db8:1:149::9
domain podlipou.doma
student@student:~$
Obr. 05-02 výpis souborů /etc/host.conf a /etc/resolv.conf
Další konfigurační soubor související s překladem jmen a IP adresy je /etc/resolv.conf , obr.
05-02. Tento soubor obsahuje základní informace pro překlad jmen na adresy v DNS systému. Jednotlivé položky značí.

nameserver , udává IP adresu DNS serveru, který zajišťuje překlad. Soubor
/etc/resolv.conf může obsahovat až tři záznamy nameserver s různými IP adresami. Tím se vytváří odolnost proti výpadkům serverům.
61
/etc/resolv.conf□

domain nebo search , specifikuje doménu, která se má aplikovat na neúplné jméno. Například, pokud se chceme spojit telnetem s uzlem ddd.podlipou.doma , můžeme zadat pouze v příkazu telnet jméno ddd . Resolver doplní doménu a vznikne
úplný doménový název ddd.podlipou.doma . Soubor resolv.conf může obsahovat
buď domain nebo search , nikoliv obě specifikace.
Výše uvedené popisy souborů, které souvisejí s organizací a překladem jmen na IP adresu
jsou pouze orientační, neúplné. Detailní popisy lze najít pomocí příkazu v Linuxu man nebo
info . Další vyčerpávající popisy jsou v literatuře [Linux_0503], [O’Reilly_0505], [Debian_0502] a [RedHat_0503].
5.2 Windows a jména
Operační systém Windows organizuje práci v sítí buď na principu domén, home group a
work group. Síť home group je nová síťová organizace definovaná od Windows 7 a je nadstavbou starší organizaci work group, [Microsoft_0503]. Doménový princip organizace sítě
potom souvisí s aplikací Windows serverů, hlavně ActiveDirectory. V případě organizace sítě
home work se používají jména pro síť home work a pro počítač, vzájemně oddělená lomítkem. Jména v operačním systému Windows se využívají pro nastavení sítí jsou založena
jednak na NetBios jménech a klasických doménových jménech. Detailní popis formátu
NetBios jmen a příslušných konfiguračních souborů je v literatuře [Microsoft_0501] a [Microsoft_0502].
.
doma
localhost
zahrada
zalesem
zalesem
podlipou
disk
zalesem
www
disk
nachate
ucet
www
vemeste
mimo
oddych
www
ulice
disk
disk
www
ucet
disk
petr
jan
Obr. 05-03 Strom doménových jmen
62
/etc/host.conf□
5.3 Prostor doménových jmen
Domain Name Space je prostor, ve kterém jsou organizované jména do stromové struktury.
S principem doménových jmen se lze setkat i v jiných systémech než DNS, proto další výklad
se snaží o zevšeobecnění i pro jiné použití. Základem je kořen stromu, který je označován
tečkou . . Jedná se vlastně o kořenovou doménu. Na tento kořen navazují další uzly, které
se nazývají uzly první úrovně, které zároveň odpovídají doménám první úrovně, obr. 05-03.
Na uzly první úrovně navazují uzly druhé úrovně a odpovídají doménám druhé úrovně.
Tímto principem lze pokračovat, dokud není definován list stromu. Každý uzel stromu, který
není listem, vytváří opět doménu, někdy se požívá termín subdoména. Uzly v doméně o
jednu úroveň níže musí mít rozdílné názvy. Ale v různých doménách mohou být stejné
názvy. Maximální počet úrovní je většinou dán implementací. Počet uzlů v doméně se
většinou neomezuje. List může být na libovolné úrovni grafu, i na první úrovni, např. localhost .
Zápis doménového jména se provádí sledem názvů uzlů od nejnižší úrovně až po kořen. Je
dobrým zvykem jednotlivé názvy oddělovat tečkou. Kořen, který je vyjádřen tečkou, se píše
pouze ve speciálních případech, jinak se nepíše. Ukázka zápisu doménových jmen je:






petr.disk.nachate.mimo
nachate.mimo
mimo
disk.mimo
disk.vemeste
localhost
Poznámka k doméně
V našem případě lze doménu definovat jako část stromu, která má společnou cestu. □
Poznámka ke grafu typu strom s kořenem



Strom s kořenem je graf, kde kořenový vrchol je předem
dán. Na tento vrchol navazují další uzly grafu. Takovýto
graf se chápe jako orientovaný, kde hrany mají orientaci od
kořene k uzlům.
Pokud uzly grafu na sebe navazují, potom se používá terminologie rodič (parents) a dítě (child).
Uzel, který nemá pokračování se list (leaf). □
kořen
R
D
D
63
5.4 Prostor doménových jmen v DNS
Systém DNS je jedním z pilířů Internet a na jeho základě se přistupuje k jednotlivým služ□
bám. Systém vychází z principu doménových jmen, definuje vlastnosti názvů domén, jejich Domény a DNS
hloubku a názvosloví. Blíže o prostoru doménových jmen v systému DNS pojednává
[wiki_0503] a [wiki_0504].
Doménové jméno se skládá ze zřetězených názvů oddělených tečkou . , například
example.org . Vlastnosti jsou:

Název uvedený nejvíce vpravo je doména prvního řádu, Skupina domén prvního řádu se nazývá TLDs – Top Level Domains. Například do-
en .wikipedia .org
ménové jméno www.example.org patří do
cs .wikipedia .org
domény nejvyšší úrovně s názvem com .


Hierarchie domén, pořadí názvu zleva je od listu
nebo od domény nižšího řádu až k doméně nejvyššího řádu. Nejvíce vpravo je doména prvního
řádu, TLD.
Každý název o úroveň níž vytváří subdoménu,
Název vlevo je subdoména názvu vpravo. Na-
stan .podlipou .ulice .ostrava .example
Obr. 05-04 ukázka doménových jmen
příklad, www.example.org je subdoména example.org .


Strom může obsahovat až 127 úrovní a každý název může obsahovat 1 až 63 bytů.
Prázdný název je rezervován pro kořen stromu. Celkově, doménové jméno nesmí
překročit 253 ASCII znaků v jejich textové reprezentaci, RFC 1035. Ve skutečnosti,
mohou existovat další omezení dané registrátorem domén.
Pro zápis názvu v doménových jmenech podle RFC 1035 se používají znaky velkých
□
písmen A až Z, malých písmen a až z, číslice 0 až 9 a pomlčky „-“, vše zapsáno v ASCII A – Z, a – z, 0 -9 a kódu. Každý název v doménovém jménu musí začínat písmenem a je citlivý na velikost písmen.
Poznámka k hostname

V Linuxu
soubor
/etc/hostname
obsahuje
petr
a
konfigurační
soubor
/etc/resolv.conf obsahuje řádek s domain example.org , potom hostname může
být v pouze petr nebo v plném názvu FQDN petr.example.org .

hostname
sestavený z prostoru doménových jmen DNS splňuje FQDN a nemusí
odpovídat
hostname , který je sestavený ze souboru /etc/hostname a
/etc/resolv.conf.

Příkaz Linuxu hostname , hostname -f , hostname -d a domainname
.□
64

Pravidlo citlivosti na velkost písmem se v praxi neuplatňuje a velká písmena jsou automaticky převedena na malá písmena, (Chrome, IExplorer a Firefox). Internacionalizace doménových jmen však používá kódování znaků podle Unicode.

Hostname je doménové jméno, kterému je přiřazena IP adresa. Například,
□
www.example.org i example.org je hostname , v případě aplikace wildcard v DNS Hostname
záznamech. Ale org již není hostname , nemá IP adresu.
.
Special-Use Domain
Names
(Reserve TLD)
T
L
D
2.
úr
ov
eň
localhost
Country Code TLD
net
org
at
example
com
pl
edu
(Reverse DNS
lookup)
sk
arpa
ge
cz
ip6
example.com
y.ip6.arpa
firma
vsb
in-addr
uri
3.
úr
ov
eň
4.
úr
ov
eň
Generic TLD
Infrastructure
domain
fs
www
fei
zavod1
zavod2
ftp
comtech
ftp
www
Special-Use Domain
Name
Generic TLD
Infrastructure
domain
(Reverse DNS
lookup)
Country Code TLD
Obr. 05-05 Strom doménových jmen
65
V systému DNS jsou doménové jména organizována podle obr. 05-05. Na kořen navazují
TLD - Top Level
domény první úrovně, pro které je známější název domény nejvyšší úrovně – TLDs. Na tyto
Domain□
domény navazují další úrovně, domény druhé úrovně, domény třetí úrovně. Pokud uzel
nemá pokračování, potom se jedná o list. Samotný list může odpovídat hostname , a celé
domové jméno potom tvoří FQDN.
Aby se zajistila jednoznačnost jmen subdomény v dané doméně, je definován vždy správce
□
domény nebo administrátor domény. Správce TLD domény organizuje činnost v doméně a Hierarchie
stráží jedinečnost názvů pouze v doméně o úroveň níže. Správce TLD domény nemá znalosti
o nižším členění, tyto znalosti má správce domény druhé úrovně. Tímto principem se vytváDistribuce□
ří hierarchie a distribuce zodpovědnosti za správu domén.
TLD domény s kořenem vytvářejí zónu kořene systému DNS a databáze TLD domén je
spravována IANA. Názvy TLD domén a pravidla tvorby názvů jsou potom schvalovány na
kongresech ICANN. V literatuře převažuje následující dělení na podskupiny:

gTLD – generic TLD, generické TLD domény, které jsou spravovány IANA. Skupina se
dále dělí na:
 Neomezené domény gTLD, kde typickým příkladem jsou nejstarší domény
.com , .org , .net a další.

Sponzorované domény gTLD, registrace v těchto doménách je podmíněna.
Název domény souvisí s určitou organizací, odvětvím podnikání a dalšími
omezeními. Například domény .edu , .gov , .museum , .post , .travel a dal-

ší.
Geografické gTLD, ggTLD - geografic generic TLD, jedná se většinou o sponzorované domény, které jsou odvozeny od celku majícího společné vlastnosti. Jedná se o domény například, .paris , .cat , .asia , .tatar , .kiwi

a
další.
ccTLD – country code TLD, názvy domén odvozené od států. Tyto domény jsou
spravovány autoritou v daném státě, v česku je to CZNIC. Příkladem jsou domény
.us , .cz , .uk a další.

Internacionalizované doménové jména, IDN – Internationalized Domain Name, jedná se domény, kde se aplikuje národní abeceda. Tato skupina se uvádí jako samostatná skupina, protože s ní souvisí množství dalších pojmů. Internacionalizace doménových jmen se týká hlavně skupiny ccTLD domén, a začíná pronikat do generických domén gTLD. Například se jedná o ccTLD domény .இந்தியா, .भारत, .გე, .新加
坡 a další.

Domény pro speciální použití, jedná se o skupinu domén, které spravuje IANA a
jsou definovány RFC, například .localhost , .example a další.

Infrastrukturní TLD doména, jedná se TLD doménu .arpa , která byla prvotně určena
k překladu IP adresy na doménové jméno a dnes jsou zde možné další překlady,
hlavně překlady týkající se telefonie.
66
V následujícím jsou uvedeny skupiny TLD domén, tak jak se s nimi můžeme setkat
v literatuře.
Poznámka k prodeji doménových jmen
Nejdráž prodané doménové jméno k roku 2014 jsou:




Insurance.com, prodána za $35.6 milionů v roce 2010.
VacationRentals.com, prodána za $35 milionů v roce 2007
PrivateJet.com, prodaná za $30.1 milionů v roce 2012
Sex.com, prodána za $24 milionů v listopadu 2014
Zdroj: http://en.wikipedia.org/wiki/List_of_most_expensive_domain_names □
5.5 Domény pro speciální použití
Special-Use Domain Names, domény pro speciální použití, jedná TLD domény a vyjmenova- Rezervované
né domény na nižších úrovních, [IANA_0501], RFC 6761 a RFC 6762. Tyto domény se v praxi domény□
často označují jako rezervované domény, [wiki_0508]. Tyto domény jsou definované proto,
aby se snížila pravděpodobnost konfliktů a zmatků. Účelem rezervovaných domén je použití
doménových jmen v dokumentaci, vytváření testovacích scénářů či předem definované
přiřazení doménového jména k IP adrese. Rezervované domény jsou definovány jednak
úrovni TLD a také na druhé úrovni, RFC 6761 a RFC 6762. Rezervované domény mají
v systému DNS velké omezení, např. rezervované TLD domény nemohou být zaneseny do
kořenových DNS serverů. Ucelený seznam reservovaných domén pro speciální použití je na
[IANA_0501]. Jedná se o domény:

localhost. , tato doména a její subdomény mohou být uživateli volně použity. Doméně .localhost. je v místním systému DNS počítače přiřazena adresa zpětné localhost.□
smyčky, 127.0.0.1 pro IPv4 a ::1 pro IPv6, [wiki_0506], RFC 6761.
Poznámka k localhost
Rozlišujeme pojem localhost jako hostname a doména .localhost , [wiki_0507] a [wiki_0506].□

invalid. , tato doména a její subdomény mohou být uživateli volně použity. Tato
doména je někdy používána jako pseudo-doména v URI, aby pokryla buď chybovou invalid.□
podmínku, nebo byla použita pro ochranu soukromí, [wiki_0505]. RFC 6761 neomezuje používání domény .invalid a jejich subdomén, s tím že překládat pomocí DNS
vrací odpověď NXDOMAIN response . Ale takto vytvořené doménové jména mohou
být zpracovány aplikačním softwarem, RFC 6761.
67

test. , tato doména a její subdomény mohou být uživateli volně použity. Ale, neexistence centrální autority, která by spravovala doménu .test. může vést k při pře- test.□
kladu k různým výsledkům, RFC 6761.

example. , example.com. , example.org. a example.net. , tyto domény a jejich subdomény jsou chápany jako domény pro dokumentační účely.

example□
local. , je doména, jejíž platnost je omezena na lokální linku, podsíť. Tato doména
se používá ve tvaru single-dns-label.local. pro multicast DNS na lince. Ukázkové
doménové jméno je MyComputer.local. .

local.□
yyy.in-addr.arpa. a z.ip6.arpa. , kde „yyy“ a „z“ jsou předem definované čísla. Jedxxx.in-addr.arpa.
y.ip6.arpa.□
ná se o domény pro zpětný překlad a detailní výčet je uveden na [IANA_0501].
Poznámka k NXDOMAIN response
NXDOMAIN je to příznak ve významu non-existent Internet or Intranet domain name,
neexistující doména, [Internet_0503].□
5.6 Generické TLD
Generické domény nejvyšší úrovně, gTLD – generic Top Level Domain, jsou domény InternegTLD –
tu spravované IANA. Zároveň, do této skupiny patří domény, které byly prvně definované
generic TLD□
v prostředí Internetu. K těmto doménám se váže pojem historické domény, které byly
definovány RFC 920 v říjnu 1984. Jedná se o domény .com , .org , .edu , .gov a .mil . Při
první implementaci byla doplněna doména .net , [wiki_0509]. Do dnešního dne, původní
Historické
historický seznam generických domén byl několikrát rozšířen, včetně internacionalizace domény□
doménových jmen. Dnes se generické TLD domény dělí do dvou základních skupin:

Neomezené TLD domény. Jedná se o domény, ve kterých doménu druhého řádu
může získat kdokoliv jako osoba a jakákoliv organizace. Dnes se jedná o domény
.com , .org , .net , a .info .

Sponzorované domény. Jedná se o skupiny domén, a kterými stojí privátní agentury nebo organizace, která ustanovují podmínky pro registraci domén druhého
řádu. Z historických domén dnes do této skupiny patří .edu , .gov a .mil . Doména .int je IANA. Z novějších sponzorovaných domén je typickým příkladem sponzorovaná doména .aero , která je sponzorována „Société Internationale de
Télécommunications Aéronautiques“, a omezuje registraci domén pouze pro organizace, společnosti působící v letecké přepravě. Například,
http://www.prg.aero/cs/ , je odkaz na letiště Václava Havla v Praze. Další sponzorované TLD domény jsou .beer , .post , .museum , a další. Úplný platný se-

znam TLD domén včetně sponzorovaných je [IANA_0502]
base; http://www.iana.org/domains/root/db.
Geografic TLD – geografické TLD domény.
Root Zone Data-
68
Sponzorované
domény□
Poznámka k historii domény .com
Zajímavý se seznam je prvních domén druhého řádu v doméně .com . Doména byla definovaná RFC 920 v říjnu 1984 a výběr z první stovky registrovaných domén vybírám:
Poř.
5.
7.
9.
11.
11.
13.
13.
15.
26.
Datum
September 30, 1985
January 9, 1986
March 3, 1986
March 19, 1986
March 19, 1986
March 25, 1986
March 25, 1986
April 25, 1986
September 2, 1986
Doména
DEC.com
xerox.com
HP.com
IBM.com
sun.com
intel.com
TI.com
ATT.com
boeing.com
Poř.
28.
42.
42.
49.
64.
73.
81.
86
94.
Datum
September 29, 1986
November 17, 1986
November 17, 1986
December 11, 1986
February 19, 1987
May 14, 1987
July 27, 1987
September 3, 1987
October 14, 1987
Doména
siemens.com
adobe.com
AMD.com
3Com.com
Apple.com
cisco.com
lockheed.com
SCO.com
WYSE.com
Úplný seznam pro doménu .com je na
http://en.wikipedia.org/wiki/.com#List_of_oldest_com_domains
a pro zbývající historické domény na
http://en.wikipedia.org/wiki/List_of_the_oldest_currently_registered_Internet_domain_n
ames. □
5.7 Geografické TLD domény
Geografické domény nejvyšší úrovně, geoTLD – geographic Top Level Domain, jsou genericGeografické
ké TLD domény, jejichž jména či vyvolávané asociace souvisí s geografickou, geopolitickou,
gTLD□
etnickou, jazykovou nebo kulturní komunitou, [wiki_0511].
V dnešní době jsou jako geografické TLD domény registrovány hlavně světové kontinenty a
města. Například, .lat je Latinská Amerika, .asia , .london , .москва – Moskva, .‫اب وظ بي‬
geoTLD –
pro Abu Dhabi, .深圳 pro Shenzhen a další. Doména .eu není geografická TLD doména, geographic TLD□
ale ccTLD doména.
5.8 TLD domény podle států
Nejvyšší domény podle států, ccTLD – country code Top Level Domain, jsou domény Inter- ccTLD –
□
netu odvozené od zemí - country, svrchovaných států - a sovereign state nebo závislých country code TLD
teritorií. Názvy ccTLD domén dvou písmenové názvy dané standardem ISO 3166-1 alpha-2a.
IANA jako správce kořenové domény deleguje správu domény ccTLD domény na národního
registrátora, podle RFC 1591. Potom registrátor ccTLD domény dále definuje pravidla registrace v dané doméně. Více informací je v [wiki_0510].
I v této kategorie existuje skupina význačných domén, které byly registrovány mezi prvními.
□
Jedná se o ccTLD domény .us , .uk a .il , které byly registrovány již v roce 1985 a domény První registrace
.au , .de , .fi , .fr , .jp , .kr , .nl a .se , v roce 1986.
69
Platný seznam ccTLD domén zohledňuje současné politické a geografické změny a proto
některé ccTLD domény zanikají a nové vznikají. Typickým příkladem je doména .cs , která již
není registrována a namísto ní jsou nově registrovány domény .cz a .sk . ISO 3166 přechodně rezervuje kód CS pro Srbsko a Černou Horu, ale jako ccTLD doména .cs nikdy
nebyla přiřazena Srbsku a Černé Hoře. Další vývoj vedl k vzniku ccTLD domén .rs pro Srbsko a .me pro Černou Horu. Doména .eu je ccTLD doména, nikoliv geografická TLD doména, i když kód EU je v ISO 3166 pouze rezervován. Obdobných problému či vývoje je více,
[wiki_0510].
Původně ccTLD domény byly dány pouze písmeny z ASCII kódu, ale dnes je do názvu aplikováno internacionalizace doménových jmen.
Úplný platný seznam TLD domén je [IANA_0502], Root Zone Database;
http://www.iana.org/domains/root/db.
5.9 Infrastrukturní doména arpa
Tato infrastrukturní doména je také označována jako reverzní DNS. Tato skupina obsahuje
pouze jednu .arpa
doménu, která byla první doménou a v sítí ARPANET se používala
k překladu hostname
na doménové jméno. Dnes se tato doména používá k překladu
různých adres a to, [wiki_0516], detailně [IANA_0503]:

Reverzní DNS, jedná se o překlad IP adresy na doménové jméno. Za tímto účelem
byly vytvořeny subdomény .in-addr.arpa pro překlad IP adres verze 4 a .ip6.arpa
pro překlad IP adres verze 6. V těchto subdoménách jsou rezervované subdomény,
[IANA_0501], které souvisejí s neveřejnými IP adresami verze 4 a pro IP adresy verze 6 s prefixy , [IANA_0501], které souvisejí s neveřejnými IP adresami verze 4 a pro
IP adresy verze 6 s prefixy fe80::/12 , fe90::/12 , fea0::/12 a feb0::/12 .

Domény .in-addr-servers.arpa a .ip6-servers.arpa , pro hostování autoritativních
jmenných serverů pro domény .in-addr.arpa a .ip6.arpa . Více RFC 5855.

Domény .uri.arpa a .urn.arpa pro Dynamic Delegation Discovery System, jedná se
o překlady související s VoIP a SIP protokolem, více [wiki_0517], detaily RFC 3401 až
RFC 3405.

Doména .e164.arpa , jedná se o mapování telefonních čísel podle E.164 na Internet
URI, [wiki_0518], detailně RFC 6116. Jedná se o aplikace NAPTR záznamů.

Doména .iris.arpa , jedná o informační službu vyhledavající v Interner registru, RFC
4698.

Doména .ipv4only.arpa , domén pro detekování přítomnosti DNS64 a pro učení
prefixů IPv6 použitých k překladu protokolu, RFC 7050.
70
5.10 Internacionalizace doménových jmen
IDN – Internationalized Domain Name, jedná se o aplikaci národních abeced do názvů
používaných v doménových jmenech. Aplikace mohou zobrazovat celé nebo část doméno- ccTLD –
□
vých jmen v jazykově závislém skriptu. Jedná se o jazyky a abecedy, arabské, čínské, cyrilika country code TLD
a další. V případě češtiny se jedná o aplikace háčků a čárek do doménových názvů.
V aplikacích a při zobrazení názvů se používá kódování znaků Unicode, převážně formát
UTF-8. Nejdříve byla internacionalizace doménových jmen hodně spojována s TLD doménami odpovídajícím státům, ccTLD, ale dnes lze říci, že internacionalizace jmen půjde napříč
všemi doménami.
První studie o internacionalizaci doménových jmen začaly již v roce 2002 vydáním RFC 3454.
Pokračovaly v roce 2003 a vše vyústilo v roce 2010 vydáním RFC 5890 a RFC 5891. O praktickém nasazení internacionalizovaných doménových jmen začala ICANN jednat v roce
2006. Vše vyústilo v červnu 2010, kdy byly implementovány první čtyři IDN ccTLD domény.
Jednalo se o domény ‫م صر‬. , ‫ال س عودي ة‬. a ‫امارات‬. , Egypt, Saudská Arábie a Spojené arabské
emiráty. Čtvrtou doménou byla .рф pro Ruskou federaci. U arabských domén je zároveň
uplatněn přirozený princip zprava doleva.
Ještě v červnu 2010, rada ICANN odsouhlasila dalších 5 národních domén, které aplikují
ideogramy CJK. Zkratka CJK značí Čína, Japonsko a Korea. Jedná se o:

.中国 , punycode .xn--fiqs8s , zjednodušená forma a .中國 , punycode .xn--fiqz9s ,
jedná se o tradiční forma a doména .zhongguo , vše Čína. Jedná se o domény delegované pro China Internet Network Information Center (CNNIC), jako registrátora
ccTLD domény .cn ;

.香港 , punycode .xn--j6w193g , .hongkong , vše Honkong. Jedná se o domény delegované pro Hong Kong Internet Registration Corporation (HKIRC), jako registrátor
ccTLD domény .hk ;

.台湾 , punycode .xn--kprw13d , zjednodušená forma a .台灣 , punycode .xn-kpry57d jedná se o tradiční formu a doména .taiwan , vše Taiwan. Jedná se o domény delegované pro Taiwan Network Information Center (TWNIC), jako registrátora ccTLD domény .tw .
Příkladem internacionalizace doménových jmen i v jiné oblasti než států, ccTLD domény, je
aplikace v generických TLD doménách. A to doména .‫ ش ب كة‬, arabská TLD doména ve významu .web , Network; dále doména .游戏 , v překladu z čínštiny hra; dále doména
.онлайн , rusky ve významu online, [wiki_0509].
Více informací o internacionalizaci doménových jmen a návaznosti na domény států – ccTLD
domény pojednává literatura RFC 1035, RFC 3492, RFC 5890 až RFC 5895, [wiki_0512] a
[wiki_0513].
71
Internacionalizace doménových jmen v České republice je možná. Správce domény .cz je
CZ.NIC, který každé dva roky provádí průzkum na téma zavedení háčků a čárek
v doméně .cz , [Internet_0504]. První průzkum byl uskutečněn v roce 2004 mezi organiza-
cemi, kdy háčky a čárky odmítlo 89% organizací. Poslední průzkum byl uskutečněn v roce
2014, kdy háčky a čárky odmítlo 81% a 68% jednotlivců. Detailní souhrn je na [Internet_0504].
S internacionalizací doménových jmen souvisí i řada problémů, útoků, které dnes nejsou
možné. Vše souvisí s identifikátorem IRI, kdy původní URL identifikátor aplikuje ASCII kódovou tabulku, kdežto jeho nástupce IRI identifikátor používá Unicode. Z toho plynou zajímavé
důsledky.
První problém je jak psát IRI pro různé jazyky. Například, zápis doménové jméno v arabštině
‫وزارة‬-‫األت صاال ت‬.‫ م صر‬, zápis pomocí latinky je možná pouze aplikaci A-labelu a to xn---rmckbbajlc6dj7bxne2c.xn--wgbh1c . První zápis pro uživatele Internetu neznajícího arabštinu je prakticky nemožný. Zápis pomocí A-labelu z latinské klávesnice je možný, ale nic
neříkající a zůstává problém, kde jej získat. Další obdobné jazyky pro nás jsou čínština,
tamilština a další. Ale uvědomme si, že i v samotné latince mohou nastat problémy se
zápisem některých národních znaků. Například, napsat polské slovo wziął z české klávesnice je pro neznalé uživatelé problém.
Za druhý problém lze považovat připojení na podvržený web, kde obsah stránek závisí na
útočníkovi. K tomuto nevhodnému připojení může dojít mnoha způsoby. Hlavně se jedná o:


Aplikace národních abeced v doménových jménech bude vyžadovat perfektní znalost pravopisu, protože pravopisně špatně zapsané jméno může vést k připojení na
podvržený web.
Pravopis. V případě českého jazyka jsou pro některá slova možné dva tvary nebo více tvarů pro zápis podle pravidel českého jazyka. Doménová jména univerzita.cz a
universita.cz jsou pravopisně správná.

V Unicode lze najít pro jedno písmeno více Unicode pozic. Například, latinské malé
písmena e a a mají stejný tvar jako malé písmena cyriliky e a a , dále malé písmeno ɑ . Potom hypertextové odkazy en.wikipedia.org a en.wikipеdiа.org nejsou totožné, v druhém zápisu je aplikována cyrilika.
Jiný problém aplikace internacionalizace doménových jmen je z oblasti vlastnictví doménových jmen. Je otázkou, kolik a jaké doménové jména si má společnost nebo zákazník rezervovat, pravopisně správné nebo i překlepy. Toto může vést až k soudním sporům ohledně
vlastnictví.
72
5.11 Punycode
S internacionalizací doménových jmen souvisí samotný systém DNS, který uchovává
v zónových souborech překlad doménového jména na IP adresu. Ale, v zónových souborech
se používá ASCII kód, a bylo žádoucí zachovat zápis internacionalizovaných doménových
jmen opět v ASCII kódu. Proto byl definován punycode, RFC 3492, [ICANN_0501] a
[wiki_0515]. V některé literatuře se v souvislosti internacionalizaci doménových jmen
objevují i pojmy A-label a U-label, obr. 05-06. Potom:

A-label je punycode, jedná se o zápis internacionalizovaného doménového jména
pomocí malých písmen, číslic a pomlčky v ASCII kódu. Punycode A-label vždy začíná
prefixem xn-- .

U-label je zápis internacionalizovaného jména pomocí Unicode. Jedná se o tvar, jak
jej má vidět uživatel.
U-label
Punycode A-label
xn----rmckbbajlc6dj7bxne2c.xn--wgbh1c
Obr. 05-06 U-label a A-label
U-label píše uživatel jako IRI do prohlížeče Internetu pomocí Unicode a mělo by být zobrazováno v daném skriptu. Ale v komunikaci s DNS systémem je použit punycode. To značí, že
DNS systém překládá punycode na IP adresu.
Punycode začíná prefixem xn-- a obsahuje pouze malá písmena a až z , číslice 0 až 9 a
pomlčka - . Jsou definované algoritmy RFC 3492 pro převod Unicode do punycode a zpětně.
V aplikacích se používá pro převod Unicode do punycode procedura s názvem ToASCII a
zpětná procedura má název ToUnicode. Potom pro zápis IRI v prohližeči Internetu lze
doménové jméno zapisovat pomocí Unicode nebo punycode. Prohlížeč provede příslušné
konverze.
Organizace domény se zapisuje do zónových souborů formou RR záznamů. RFC 1035 z roku
1987 definuje, že záznamy budou zapsány pomocí 7 bitového ASCII. Tato praxe potom
zajištuje jednoznačnost a možnost čtení RR záznamů. Aplikace Unicode do zónových souborů by mohla narušit čtení, protože operační systém nemusí mít instalovány všechny skripty
Unicode. Za další je problém jednoznačnosti zápisu názvu v některých jazycích, hlavně
pomocí ideogramů. Potom jednomu názvu může odpovídat více ideogramů, řekněme
tradiční a zjednodušený. Potom ale vyvstává problém jednoznačnosti RR záznamů pro
73
neznalé čitatelé. Aplikace punycode do zónových souborů zajištuje jednoznačnost a možnost čtení RR záznamůNa obr. 05-07 je ukázka zónového souboru s punycode pro doménu
háčkyčárky.cz , [Internet_0504].
$ORIGIN xn--hkyrky-ptac70bc.cz.
$TTL 1m
@
IN
SOA
a.ns.xn--hkyrky-ptac70bc.cz. hostmaster.nic.cz. (
1
; serial number
10800
; refresh
3600
; update retry
1209600
; expiry
7200
; minimum
)
@
@
IN
IN
NS
NS
a.ns.xn--hkyrky-ptac70bc.cz.
b.ns.xn--hkyrky-ptac70bc.cz.
a.ns
a.ns
:
:
:
IN
IN
A
AAAA
194.0.12.1
2001:678:f::1
Obr. 05-07 Zónový soubor
5.12 Reference
[Centos_0501] 28.1.21. /etc/sysconfig/network;
http://www.centos.org/docs/5/html/5.2/Deployment_Guide/s2-sysconfignetwork.html; on line 2015-01-21
[Debian_0501] 3.2.5. The hostname; http://www.debian.org/doc/manuals/debianreference/ch03.en.html#_the_hostname; on line 2015-01-21
[Debian_0502] Chapter 5. Network setup; http://www.debian.org/doc/manuals/debianreference/ch05.en.html; on line 2015-01-21
[IANA_0501]
Special-Use Domain Names; http://www.iana.org/assignments/special-usedomain-names/special-use-domain-names.xhtml; on line 2015-01-21
[IANA_0502]
Root Zone Database; http://www.iana.org/domains/root/db; on line 201501-21
[IANA_0503]
.ARPA Zone Management; http://www.iana.org/domains/arpa; on line
2015-01-21
[ICANN_0501] IDN Glossary; https://www.icann.org/resources/pages/glossary-2014-0204-en; on line 2015-01-21
[Internet_0501]What is the difference between a hostname and a domain name;
http://support.suso.com/supki/What_is_the_difference_between_a_hostn
ame_and_a_domain_name; on line 2015-01-21
74
[Internet_0502]How to set hostname and FQDN on CentOS 7 and RHEL 7;
http://sharadchhetri.com/2014/09/27/set-hostname-fqdn-centos-7-rhel7/; on line 2015-01-21
[Internet_0503]DNS Knowledge; http://www.dnsknowledge.com/whatis/nxdomain-nonexistent-domain-2/; on line 2015-01-21
[Internet_0504]IDN - INTERNATIONALIZED DOMAIN NAMES; http://xn--hkyrkyptac70bc.cz/; on line 2015-01-21
[Linux_0503]
kolektiv autorů: Linux – Dokumentační projekt; 3. aktualizované vydání;
Computer Press 2003; ISBN 80-7226-761-2
[Microsoft_0501]
NetBios name; http://technet.microsoft.com/enus/library/cc784180(v=ws.10).aspx; on line 2015-01-21
[Microsoft_0502]
Microsoft WINS Clients; http://technet.microsoft.com/enus/library/cc959259.aspx; on line 2015-01-21
[Microsoft_0503]
What is the difference between a domain, a workgroup, and a
homegroup?; http://windows.microsoft.com/en-us/windows7/what-is-thedifference-between-a-domain-a-workgroup-and-a-homegroup; on line
2015-01-21
[O’Reilly_0505] M. K. Dalheimer and M. Welsh: Running Linux, Fifth Edition; O’Reilly 2005;
ISBN-13: 978-0-596-00760-7
[RedHat_0501] Chapter 32. The sysconfig Directory;
https://access.redhat.com/documentation/enUS/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/chsysconfig.html#s2-sysconfig-network; on line 2015-01-21
[RedHat_0502] 9.7. Setting the Hostname; https://access.redhat.com/documentation/enUS/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/sn-Netconfigx86.html; on line 2015-01-21
[RedHat_0503] RED HAT ENTERPRISE LINUX 7 NETWORKING GUIDE;
https://access.redhat.com/documentation/enUS/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/index.html; on
line 2015-01-21
[RFC_1035]
DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION;
[RFC_3492]
Punycode: A Bootstring encoding of Unicode for Internationalized Domain
Names in Applications (IDNA); http://tools.ietf.org/html/rfc3492; on line
2015-01-21
[RFC_6761]
Special-Use Domain Names; http://tools.ietf.org/html/rfc6761; on line
2015-01-21
[RFC_6762]
Multicast DNS; http://tools.ietf.org/html/rfc6762; on line 2015-01-21
[wiki_0501]
Hostname; http://en.wikipedia.org/wiki/Hostname; on line 2015-01-21
75
[wiki_0502]
Fully qualified domain name;
http://en.wikipedia.org/wiki/Fully_qualified_domain_name; on line 201501-21
[wiki_0503]
Domain Name System;
http://en.wikipedia.org/wiki/Domain_Name_System; on line 2015-01-21
[wiki_0504]
Domain Name; http://en.wikipedia.org/wiki/Domain_Name; on line 201501-21
[wiki_0505]
.invalid; http://en.wikipedia.org/wiki/.invalid; on line 2015-01-21
[wiki_0506]
.localhost; http://en.wikipedia.org/wiki/.localhost; on line 2015-01-21
[wiki_0507]
localhost; http://en.wikipedia.org/wiki/localhost; on line 2015-01-21
[wiki_0508]
Reserved domains; http://en.wikipedia.org/wiki/Toplevel_domain#Reserved_domains; on line 2015-01-21
[wiki_0509]
Generic top-level domain; http://en.wikipedia.org/wiki/Generic_toplevel_domain; on line 2015-01-21
[wiki_0510]
Country code top-level domain;
http://en.wikipedia.org/wiki/Country_code_top-level_domain; on line
2015-01-21
[wiki_0511]
GeoTLD; http://en.wikipedia.org/wiki/GeoTLD; on line 2015-01-21
[wiki_0512]
Internationalized domain name;
http://en.wikipedia.org/wiki/Internationalized_domain_name; on line
2015-01-21
[wiki_0513]
Internationalized country code top-level domain;
http://en.wikipedia.org/wiki/Internationalized_country_code_toplevel_domain; on line 2015-01-21
[wiki_0514]
IDN homograph attack;
http://en.wikipedia.org/wiki/IDN_homograph_attack; on line 2015-01-21
[wiki_0515]
Punycode; http://en.wikipedia.org/wiki/Punycode; on line 2015-01-21
[wiki_0516]
Top-level domain; http://en.wikipedia.org/wiki/Top-level_domain; on line
2015-01-21
[wiki_0517]
Dynamic Delegation Discovery System;
http://en.wikipedia.org/wiki/Dynamic_Delegation_Discovery_System; on
line 2015-01-21
[wiki_0518]
Telephone number mapping;
http://en.wikipedia.org/wiki/Telephone_number_mapping; on line 201501-21
76
6 Unicode
Původně doménové jméno bylo psáno pouze anglickou abecedou. Používalo se kódování
ASCII tabulky, [Internet_0601]. Názvy nemohly používat diakritiku. S nástupem personálních
počítačů se začala používat diakritika a objevily se kódové stránky. Zavedení kódových
stránek přinášelo problémy a neřešilo problém národních abeced komplexně. Více o problému kódových stránek je v literatuře [wiki_0601], [wiki_0602], [wiki_0603], [wiki_0604],
[wiki_0605], [wiki_0606]. Proto v 90 letech 20 století vznikla skupina, která si dala za cíl
definovat jeden princip kódování pro všechny národní abecedy celého světa. Vzniklý Unicode je základem internacionalizace doménových jmen.
Unicode je kód, který umožňuje kódovat jakékoliv světové
abecedy. Předcházející pokusy byly velmi problematické.
Nutno si uvědomit, že na celém světě jsou živé a mrtvé
jazyky. Živé jazyky jsou používány lidmi dnešního světa.
Mrtvé jazyky jsou historické jazyky jako například egyptské
hieroglyfy, indiánské jazyky atd. Proto je žádoucí, aby
existovalo universální kódování znaků všech abeced. Také,
dnešní dokumenty nejsou jen textové, ale mohou obsahovat vědecké symboly, historické symboly, grafické informace, zvukové informace,
atd. Práce na novém standardu začaly začátkem 90 let minulého století. Vznikly dvě
skupiny, které se problému věnovaly a to Unicode a ISO/IEC. Unicode doporučení
bylo také publikováno jako ISO/IEC standard, protože závěru obou skupin byly velmi
blízké. Ale známější je pojem Unicode a poslední verze je 7 z roku 2014.
“Unicode is a computing
industry standard for
the consistent encoding,
representation and
handling of text expressed in most of the
world's writing systems.” □
Source
http://en.wikipedia.org/wiki/Unicode
Dnes, význam Unicode spočívá v nasazení v reálné praxi a ve formě formátu UTF se s ním
můžeme setkat v, [wiki_0607]:





UTF-8 se stal dominantním kódováním znaků v prostředí World Wide Web
Internet Mail Consortium (IMC) doporučuje, aby všechny programy elektronické
pošty zobrazovaly a používaly formát UTF-8.
Konsorcium W3C doporučuje UTF-8 jako defaultní kódování v jejich standardech týkajících se XML a HTML
UTF-8 je také velmi rozšířené kódování používané v operačních systémech, programovacích jazycích, API – aplikačních rozhraních a počítačových aplikacích, [wiki_0607]
UTF-8 je defaultní kódování Internetu, [oracle_0601].
77
U+0031 DIGIT ONE 1
U+xxxx JMÉNO ZNAKU TVAR
U+
Název znaku
Hexa číslo
tvar
Pořadí není povinné
Obr. 05-01 Zápis znaku v Unicode
Unicode používá 1 114 112 kódových bodů a odpovídající rozsah kódových pozic je od 0 do
0x10 FFFF. Jedná se 21 bitový prostor, kde každý znak je definován Unicode pozicí nebo
kódovou pozicí – Unicode point or code point, jménem a základním tvarem, obr. 06-01.
Každá část této definice má svoje pravidla zápisu a pořadí není povinné.



Unicode pozice je hexadecimální číslo, které odpovídá znaku. Je povinné uvádět pozici minimálně na čtyři hexadecimální číslice. Z toho plyne, že kódové pozice z Basic
Multilingual Plane se zapisují 4 číslicemi.
Unicode jméno je textový název či popis znaku. Standard používá k zápisu malé kapitálky.
Základní tvar - basic glyph, je grafická reprezentace znaku [wiki_0608]. Typeface potom může měnit grafickou reprezentaci.
Příklad definice znaku
U+25B3 - WHITE UP-POINTING TRIANGLE (trime) △
U+2624 - CADUCEUS ☤
U+1F638 - GRINNING CAT FACE WITH SMILING EYES 😸
□

Poznámka ke kódovacímu prostoru
Původně Unicode byl definován do 32 bitového prostoru a později tento prostor byl
omezen na 21 bitů. Proto je Unicode známý jako 32 bitové kódování znaků. □
21 bitový prostor Unicode je rozdělen do 17 rovin a každá rovina obsahuje 65 536 kódových
pozic. To znamená, že každá rovina používá 16 bitový prostor, kde 216 = 65 536 a 17 * 65
536 = 1 114 112 kódových pozic. Každá rovina je charakterizována svým číslem a názvem,
zkratkou a rozsahem, obr. 06-02.
78
U
n
i
c
o
d
e
r
o
v
i
n
y
B
a
s
i
c
S
u
p
p
l
e
m
e
n
t
a
r
y
0000 - FFFF
Rovina 0
BMP
Basic Multilingual Plane
1 0000 – 1 FFFF
Rovina 1
SMP
Supplementary Multilingual
Plane
2 0000 – 2 FFFF
Rovina 2
SIP
Supplementary Ideographic
Plane
3 0000 – D FFFF
Rovina 3 – 13
-
E 0000 – E FFFF
Rovina 14
SSP
F 0000 – 10 FFFF
Rovina 15 - 16
S PUA
A/B
Unassigned
Supplementary Specialpurpose Plane
Supplementary Private Use
Area
Obr. 06-02 Definice Unicode rovin
Základní rovina - Basic plane 0, má zkratku a název BMP – Basic Multilingual Plane, [wiki_0609]. Tato rovina je důležitá a obsahuje skripty všech živých světových jazyků a ostatní
grafické symboly. Prvních 256 pozic, 0 až 0x00FF odpovídá kódové stránce ISO 8859-1 a
řídícím kódům C0 a C1. Z čehož plyne, že prvních 128 kódových pozic, 0 až 0x7F odpovídá Unicode začíná
□
ASCII 7 bitovému kódu. ASCII 7 bitový kód je podmnožinou ISO 8859-1. Zápis kódové pozice ASCII kódem
ve formátu UTF-8 má stejnou hodnotu jako ASCII 7 bitový kód. UTF-8 zajišťuje zpětnou
kompatibilitu s ASCCI kódem.
Zbývající kódové pozice v BMP obsahují skripty všech moderních světových jazyků. Potom
BMP obsahuje skripty pro Cyriliku, arabské písmo, čínské, japonské a korejské tvary atd. To
znamená, že většina světových dokumentů vystačí s BMP rovinou - Basic Multilingual Plane.
Supplementary plane 1 má jméno SMP - Supplementary Multilingual Plane, [wiki_0609].
Tato rovina obsahuje historické skripty, jako jsou egyptské hieroglyfy, jazyk Mayů a další.
SMP rovina také obsahuje matematické alfanumerické symboly, dnešní a historické symboly pro hudbu, symboly pro hry, symboly hracích karet, Mahjong, domino atd.
Supplementary plane 2 má jméno SIP - Supplementary Ideographic Plane, [wiki_0609]. Tato
rovina obsahuje CJK ideogramy [wiki_0612], které nejsou zahrnuty v předchozích rovinách.
Supplementary planes 3 to 13 jsou roviny, které jsou označovány jako nepoužité roviny.
Supplementary plane 14 má jméno SSP - Supplementary Special-purpose Plane, [wiki_0609]. Tato rovina v současnosti obsahuje ne-grafické znaky. SSP rovina obsahuje blok
tagů, které jsou pro staré jazyky používající tagy a používají se, když jazyk nemůže být
indikován pomocí ostatních protokolů.
79
Supplementary planes 15 a 16 mají jméno SPUA A/B - Supplementary Private Use Area A
and B. Tyto roviny jsou určeny pro soukromé použití skupinami, které jsou mimo konsorcium ISO a Unicode.
6.1 Použití Unicode
Pro použití v oblasti informatiky a hlavně v počítačích jsou definované formáty zápisu Unicode pozice. Tento nový zápis vychází ASCII kódování a zajišťuje pokrytí celého 21 bitového
prostoru Unicode. Unicode definuje tři formáty zápisu, 8 bitový, 16 bitový a 32 bitový zápis.
Názvy těchto formátů jsou UTF-8, UTF-16 a UTF 32.
6.2 UTF-32
Tento zápis používá 32 bitová slova. Unicode pozice mí maximálně 21 bitů. V UTF-32 je 21
□
bitová Unicode pozice doplněna nulovým prefixem do 32 bitů. Takto vytvořené číslo je zápis UTF-32
kódové pozice v UTF-32 formátu. Jinak, UTF-32 formát přímo odpovídá Unicode pozici,
[wiki_0610]. Programovací jazyk Python od verze 3.2 používá UTF-32 jako jednotnou kódovací schéma, [wiki_0610].
6.3 UTF-16
UTF-16 je proměnlivou délku kódování z důvodu, aby pokryl celý 21 bitový prostor Unicode.
UTF-16 □
UTF-16 používá 16 bitoví slova a Unicode pozici kóduje do jednoho neb= dvou slov, každé o
16 bitech, [wiki_0611]. V případě dvou slov, UTF-16 používá speciální dvojici, která se nazývá surrogate pár. Jedná se o aplikaci dvou hodnot z rozsahu 0xD800 až 0xDFFF. Tyto hodnoty leží v BMP rovině a k těmto hodnotám nejsou přiřazeny znaky. Tyto hodnoty jsou vyhrazeny pro aplikaci UTF-16 formátu. UTF-16 kódování má dva principy kódování v závislosti na
hodnotě Unicode pozice.
Unicode pozice z BMP roviny jsou přímo použity v UTF-16 formátu. Tyto pozice jsou kódovány jedním slovem. První Unicode rovina je základní a je dána rozsahem hodnot 0 až
0xFFFF, pouze 16 významových bitů je použito. V tomto případě není aplikována žádná
transformace.
Když Unicode pozice leží mimo základní rovinu, potom surrogate pár je použitý a kódová
□
pozice je transformována do dvou slov. První slovo se nazývá vedoucí - lead a druhé konco- Surrogate pár
vé - trail surrogates. Vedoucí surrogate je číslo z rozsahu 0xD800 až 0xDBFF. Koncový
surrogate je potom číslo z rozsahu 0xDC00 až 0xDFFF. Algoritmus je, [wiki-0628]:



0x010000 je odečteno kódové pozice, tím vznikne číslo, které určitě má 20 významových bitů a je v rozsahu 0 to 0xFFFFF
vzniklý rozdíl je rozdělen do dvou skupin, každá po 10 bitech, takto vzniknutá čísla
jsou v rozsahu 0 až 0x3FF
číslo odpovídající vyšším 10 bitům se přičte hodnota 0xD800. Potom součet je první
Lead a trail
slovo UTF-16 formátu nebo vedoucí surrogate, který bude ležet v rozsahu 0xD800
surrogate □
až 0xDBFF. (Previous versions of the Unicode Standard referred to these as high
surrogates.)
80

Číslo odpovídající nižším 10 bitů se přičte hodnota 0xDC00, Potom součet je druhé
slovo UTF-16 formátu nebo trail surrogate, který bude ležet v rozsahu 0xDC00 až
0xDFFF. (Previous versions of the Unicode Standard referred to these as low surrogates.)
Kódovací algoritmus je znázorněn na obr. 06-03. První surrogate sekvence 0xD800 a 0xDC00
odpovídá Unicode pozici 0x010000.
Lead\Trail
D800
D801
D802
⋮
DBFF
DC00
01 0000
01 0400
01 0800
⋮
10 FC00
DC01
01 0001
01 0401
01 0801
⋮
10 FC01
DC02
01 0002
01 0402
01 0802
⋮
10 FC02
…
…
…
…
⋱
…
DFFF
01 03FF
01 07FF
01 0BFF
⋮
10 FFFF
Obr. 06-03 UTF-16 kódování pomocí surrogate páru
𤨽
U+24A3D
HAN IDEOGRAM

0x02 4A3D
-0x01 0000
0x01 4A3D

0001 0100 1010 0011 1101
Leading part
0x052
Trailing part
0x23D
UTF-16 – 0XD852 0XDE3D
Lead surrogate

0xD800 + 0x052 = 0xD852
Trail surrogate

0xDC00 + 0x23D = 0xDE3D
Obr. 05-04 Ukázka UTF-16 kódování
Ukázková aplikace výše uvedeného algoritmu je na obr. 06-04:





První krok, odečtení hodnoty 0x010000 od kódové pozice. Výsledek má maximálně
20 bitů
Druhý krok, rozdělení rozdílu na dvě skupiny po 10 bitech zprava. Rozdělení je
vhodné provést v binárním zápisu rozdílu a výsledek zpětně transformovat do hexadecimálního tvaru. Vyšších 10 bitů přináleží k lead surrogate a nižší 10 bitů k trail
surrogate
Třetí krok, lead surrogate je dán součtem 0xD800 a vyšších 10 bitů
Čtvrtý krok, trail surrogate je dán součtem 0xDC00 a nižších 10 bitů
Nakonec, UTF-16 sekvence je lead and trail surrogate
81
6.4 UTF-8
UTF-8 formát je proměnlivé délky a tím dokáže pokrýt celý 21 bitový Unicode prostor. UTF8 používá 8 bitové byty jako základní element, [wiki_0629]. UTF-8 zajištuje zpětnou kompatibilitu se 7 bitovým ASCII kódem a řeší i problém endianů ve spojitosti s UTF-16 and UTF32. Počet použitých bytů závisí na hodnotě Unicode pozici.
RFC 3629 z roku 2003 omezil maximální počet bytů mna 4 byty a tím i hodnoty v UTF-32 a
UTF-16. UTF-8 formát, kde maximálním počet bytů je 4, dokáže pokrýt Unicode prostor 0 až
0x10FFFF. Tento prostor odpovídá 21 bitové n-tici a 17 Unicode rovinám.
Základní vlastnosti UTF-8 formátu jsou, [wiki_0629]:





Existence zpětné kompatibility se 7 bitovým kódem ASCII v rozsahu 0 až 127. UTF-8
má stejné hodnoty jako ASCII kód. Nejvíce významový bit je roven nule.
Jednoznačné rozlišení jednobytové sekvence od více bytové sekvence. Unicode pozice vyšší než 127 jsou kódovány více bytovou sekvenci, kde první byty je označován
jako vedoucí - leading byte a další jako následující byty - continuation bytes.
V sekvenci více bytů má vedoucí byte vždy prefix skládající se ze dvou nebo více
jedniček následované jednou mulou. Následující byty má vždy prefix jednu jedničku
následovanou nulou, '10'.
Samo synchronizace, všechny aplikované byty jsou jednoznačně detekovatelné
jednoznačným prefixem. U všech typů bytů je různý a tato definice umožňuje samo
synchronizaci v případě, že dojde ke ztrátě libovolného počtu bytů, RFC 3629
Jednoznačná detekce délky sekvence. Počet vedoucích jedniček ve vedoucím bytů
udává počet bytů v celé sekvenci.
Kódová struktura. Mimo předem definované bity potom zbývající bity se odvozují
od Unicode pozice.
Zpětná kompatibilita □
Jednoznačnost □
Selfsynchronization □
UTF-8 sekvence bytů požívá leading a continuation byte, obr. 06-05. První byte je vedoucí
byte - leading byte, který je následovaný jedním nebo více následujícími byty - continuation
bytes. Všechny následující byty - continuation bytes jsou unikátně kódované prefixem 10B.
Unique encoding
Vedoucí byte - leading byte je unikátně kódovaný následně:
of leading byte□




Prefixem 0B, který určuje, že sekvence má pouze jeden byte, vedoucí byte - leading
byte.
Prefixy 110B, 1110B a 11110B, u těchto prefixů počet jedniček udává počet bytů
v celé sekvenci.
UTF-8 formát je samo synchronizující. Toto je důležitá vlastnost, když v sekvenci
UTF-8 bytů dojde ke ztrátě. Potom dekodér se dokáže opětně synchronizovat na
vedoucí byte a tím zachránit zbývající znaky. Dojde k sice ke ztrátě jednoho či několika znaků, ale zbývající znaky po chybě jsou opět dekódovány správně. UTF-8 formát také obsahuje předem definované invalidní kódy.
Každý znak musí být kódován nejkratší sekvenci.
82
Počet
význaŘádek
mových
bity
První
kódová
pozice
První
kódová
pozice
Leading
byte, binárně
Byte 1
Continuation bytes, binárně
Byte 2
Byte 3
1
7
U+0000
U+007F
0xxx xxxx
2
11
U+0080
U+07FF
110x xxxx
10xx xxxx
3
16
U+0800
U+FFFF
1110 xxxx
10xx xxxx
10xx xxxx
4
21
U+1 0000 U+1F FFFF
1111 0xxx
10xx xxxx
10xx xxxx
Byte 4
10xx xxxx
Source: http://en.wikipedia.org/wiki/UTF-8
Obr. 06-05 UTF-8 kódování
U+13051


EGYPTIAN HIEROGLYPH B002
0001 0011 0000 0101 0001
01 0011
000
Vedoucí
část 1
00 0001
01 0001
část 4
část 3
část 2
Následující části
Operátor “+”znamená zřetězení
UTF-8 – 0XF0 XA3 0X81 0X91

Vedoucí byte
“1111 0” + “000” = “1111 0000” => 0xF0

Následující byte 2
“10” + “01 0011” = “1010 0011” => 0xA3
“10” + “00 0001” = “1000 0001” => 0x81

 “10” + “01 0001” = “1001 0001” => 0x91
Obr. 05-06 Ukázka UTF-8 kódování
Ukázka UTF-8 kódování je na obr. 06-06. Tato ukázka je platná pouze pro Unicode pozice
vyšší než 0x7F, mimo prostor ASCII kódu. Když Unicode pozice má maximálně 7 významo- ASCII code corre□
vých bitů, potom UTF-8 přímo odpovídá této hodnotě. Pro Unicode pozice vyšší než 0x7F sponds to UTF-8
platí:



První krok, převeď Unicode pozici do binárního zápisu
Druhý krok, rozděl binární řetězec do skupin po 6 bitech od LSB. Nejvyšší n-tici nemá 6 bitů. Nejvyšší n-tice přináleží do vedoucího bytu - leading byte a zbývající ntice přináleží do následujících bytů - continuation bytes.
Třetí krok, z tabulky vyber odpovídající řádek podle počtu následujících částí - continuation parts.
83


Čtvrtý krok, vedoucí byte - leading byte vznikne zřetězením vedoucího prefixu
s příslušnou vedoucí části. Počet vedoucích jedniček udává počet následujících bytů.
Pátý krok se aplikuje na všechny následující části. Následující byte vznikne zřetězením prefixu 10B s příslušnou následující části.
6.5 ASCII kód
American Standard Code for Information Interchange – ASCII je schéma kódování znaků,
která je použita v počítačích, komunikačních zařízeních a ostatních zařízeních
pro zpracováním textů. Tento standard byl ustanoven v roce 1960 a jeho poslední modifikaASCII□
ce je z roku 1986. ASCII kód je 7-bitový kód, má pouze 128 kódových pozic, [Internet_0601].
Ve světě Internetu měl a má ASCII kód významné postavení. Do roku 2007 byly všechny
jména, související s Internetem a www, kódovány 7-bitovým ASCII kódem. Po tomto datu,
byl ve světě www ASCII kód nahrazen Unicode a formátem UTF-8, [wiki_0613]. Významnost
ASCII kódu byla zohledněna i v Unicode, kde ASCII kód je prvních 128 kódových pozic
v Unicode.
LSB
MSB
0
1
2
3
4
5
6
7
0
1
2
3
4
5
6
7
8
9
A
B
C
D
E
F
NUL SOH STX ETX EOT ENQ ACK BEL BS HT LF VT FF
DLE DC1 DC2 DC3 DC4 NAK SYN ETB CAN EM SUB ESC FS
!
"
#
$
%
&
'
(
)
*
+
,
0
1
2
3
4
5
6
7
8
9
:
; <
@
A
B
C
D
E
F
G
H
I
J
K L
P
Q
R
S
T
U
V W
X
Y
Z
[
\
`
a
b
c
d
e
f
g
h
I
j
k
l
p
q
r
s
t
u
v
w
x
Y
z
{ |
CR
GS
=
M
]
m
}
SO
RS
.
>
N
^
n
~
SI
US
/
?
O
_
o
DEL
Obr. 06-07 US ASCII kódovací schéma
Originální 7-bitový ASCII kód obsahuje dvě základní části, a to 33 řídících znaků a 95 tisknutelných znaků, obr. 0607. Řídící znaky byly hlavně definovány pro řízení znakově orientovaných zařízení, dnes má výsostné postavení kód ESC – escape, který je součástí moderních
klávesnic a také je úvodním znakem escape sekvencí nebo ANSI sekvencí. V sériové komunikaci se lze setkat s kódy SI a SO, které řídí tok dat – flow control. Co se týče písmen, mezi
kódem velkého písmene a kódem malého písmene je posunutí 20 hexa.
6.6 Reference
[oracle_0601] 23.3 Specifying a Character Set in a JSP or XML File;
http://docs.oracle.com/cd/E17904_01/bi.1111/b32121/pbr_nls003.htm;
on line 2014-08-31
[Intrenet_0601]
ASCII; http://searchcio-midmarket.techtarget.com/definition/ASCII;
on line 2013-12-27
[Unicode_0605]
Character Set; http://www.unicode.org/glossary/#character_set; on
line 2013-12-06
84
[wiki_0601]
Code page 437; http://en.wikipedia.org/wiki/Code_page_437; on line 201401-21
[wiki_0602]
Code page 852; http://en.wikipedia.org/wiki/Code_page_852; on line 201401-21
[wiki_0603]
Windows-1252; http://en.wikipedia.org/wiki/Windows-1252; on line 201401-21
[wiki_0604]
Windows-1250; http://en.wikipedia.org/wiki/Windows-1250; on line 201401-21
[wiki_0605]
ISO/IEC 8859-1; http://en.wikipedia.org/wiki/8859-1; on line 2014-01-21
[wiki_0606]
ISO/IEC 8859-2; http://en.wikipedia.org/wiki/8859-2; on line 2014-01-21
[wiki_0607]
UTF-8; http://en.wikipedia.org/wiki/UTF-8; on line 2014-01-25
[wiki_0608]
Glyph; http://whatis.techtarget.com/definition/glyph; on line 2013-12-06
[wiki_0609]
Plane (Unicode);
http://en.wikipedia.org/wiki/Plane_(Unicode)#Supplementary_Specialpurpose_Plane; on line 2014-09-24
[wiki_0610]
UTF-32; http://en.wikipedia.org/wiki/UTF32; on line 2014-01-25
[wiki_0611]
UTF-16; http://en.wikipedia.org/wiki/UTF16; on line 2014-01-25
[wiki_0612]
Ideogram; http://en.wikipedia.org/wiki/Ideogram; on line 2013-12-27
[wiki_0613]
ASCII; http://en.wikipedia.org/wiki/ASCII; on line 2014-01-25
85

Komunikační sítě I pro integrovanou výuku VUT a VŠB-TUO

Transkript

Podobné dokumenty

Aukce exkluzivního designu Čtvrtek 28. června v 18:00

version PDF en mode texte - Ampère et l`histoire de l`électricité

Informace a Internet

zde

Aukce exkluzivního designu Čtvrtek 28. června v 18:00

Slovníček pojmů kolem sítí a hlavně WiFi

Konfigurace IPv6

WDM-PON - Profiber

Kaspersky Anti-Virus for Windows Servers MP4

IPv6 - Cesnet