Vysoká škola ekonomická v Praze Internetový protokol IP

Transkript

Vysoká škola ekonomická v Praze
Fakulta informatiky a statistiky
Katedra informačních technologií
Diplomant
:
Vedoucí diplomové práce :
Miroslav Matuška
Ing. Ivo Šmejkal (VC VŠE)
TÉMA DIPLOMOVÉ PRÁCE
Internetový protokol IP verze 6
Prohlášení
Prohlašuji, že jsem diplomovou práci zpracoval samostatně a že jsem uvedl všechny použité prameny
a literaturu, ze kterých jsem čerpal.
V Praze dne 30.4.2002
strana 2
................................ ..........................
podpis
Poděkování
Autor diplomové práce by rád tímto poděkoval
• Ing. Ivo Šmejkalovi za neúnavné vedení práce, obsahové nasměrování textu práce, poskytnutí
kontaktů na další odborníky, řadu podnětných rad a zkušeností, pečlivé pročtení textu práce a
poskytnutí některých zdrojů. V neposlední řadě pak za ochotu ke konzultacím v jakémkoli
čase a příjemnou atmosféru při zpracování diplomové práce.
•
•
•
•
•
•
Vedoucímu oddělení síťové infrastruktury VC VŠE Ing. Luboši Pavlíčkovi za umožnění
vytvoření testovací sítě.
Mgr. Františku Potužníkovi a Ing. Haně Lukášové ze sdružení PASNET za pomoc při shánění
potřebné literatury a zkušebního software.
Pavolu Luptákovi a Ing. Petru Cahynovi z firmy ICZ a.s. za umožnění provedení části
zkoušek na jimi spravovaném systému.
RNDr. Pavlu Satrapovi z Technické univerzity Liberec za možnost nahlédnout do jím
připravovaného textu o zpracovávané oblasti.
Řediteli výpočetního centra VŠE RNDr. Igoru Čermákovi, CSc. za pomoc při nalezení
vedoucího práce a shánění literatury.
Všem, kteří za autora dočasně převzali jeho jiné povinnosti, aby se mohl plně věnovat
zpracování této práce, zejména pak:
o Rodičům a sestře.
o Spolupracovníkům z různých útvarů výpočetního centra, zejména oddělení správy
unixových systémů.
o A všem dalším
strana 3
Abstrakt
Současná celosvětová síť Internet je založena protokolu IP verze 4. Cílem této diplomové práce
je zjistit aktuální stav návrhu, standardizace, implementace, praktické použitelnosti a rozšíření znalostí
o nově navrženém internetovém protokolu IP verze 6 (IPv6). Smyslem práce je uspořádat informace a
znalosti, které jsou o novém protokolu k dispozici, do přehledné formy a využít je k získání dalších
poznatků praktickým testováním dostupných implementací nového protokolu v laboratorní síti.
V neposlední řadě je cílem také vytvoření textu, který by odborné i laické veřejnosti nový protokol
více přiblížil, z tohoto důvodu obsahuje práce také některé výkladové pasáže, které může zkušenější
čtenář již znát.
Teoretická část práce je vytvořena zpracováním a zhodnocením informací z mnoha různých
dostupných zdrojů, zejména anglických textů popisujících protokolové standardy. Informačním
pramenem byly i názory odborníků z některých firem a institucí a skromné vlastní znalosti autora. Ty
byly v souladu s posláním práce dále rozšířeny hlavní pasáží diplomové práce - praktickou zkouškou
instalace a implementace protokolu ve zkušební síti, která přinesla řadu dalších poznatků. Cíle práce
může být dosaženo i pomocí vlastních autorových úvah o dalších aspektech a problémech protokolu a
nástiny prognóz přechodu větších sítí. Ty jsou založeny právě na zkušenostech získaných testováním.
Přínosem práce je ucelené zmapování problémové oblasti, ke které existuje v současné době
velmi málo kvalitní literatury, a vytvoření základní referenční pomůcky, která může dalším zájemcům
rozšířit znalosti o IPv6 a pomoci jim se začátkem vlastních praktických zkoušek. Dalším přínosem
mohou být popsané výsledky zjištěné z teoretických zkoušek, na kterých se dají naznačeným
způsobem založit další, sofistikovanější zkoušky a implementace. A ještě dalším přínosem práce může
být vytvoření textu v češtině, který může pomoci šířit mezi veřejností osvětu o zatím ne příliš známém
(ale zřejmě v budoucnu nezbytném) protokolu.
Práce je rozdělena na teoretickou a praktickou část.
Teoretická část začíná krátkým zopakováním a připomenutím historických událostí, které vývoji
nového protokolu předcházely. Následuje obsáhlejší technologická pasáž, která ve shrnuje vlastnosti a
možnosti IPv6. Důležitou otázkou bude způsob přechodu ze stávajícího Internetu na nový protokol, a
proto se přechodovým mechanismům věnuji v další kapitole. Další dvě kapitoly shrnují současný stav
implementace protokolu na různých zařízeních a jeho použití v praxi. Úspěch protokolu bude záviset i
na netechnologických okolnostech, které jsou shrnuty v kapitole o ekonomických aspektech nového
protokolu. Závěrečnou kapitolou teoretické části práce je nástin některých, zvláště přechodových
problémů IPv6 a opatrné prognózy možného budoucího vývoje
Praktická část se v úvodní části zabývá stavem registrace IPv6 sítí a adresních rozsahů
s důrazem na síť Vysoké školy ekonomické v Praze. Následující kapitola podrobně popisuje vytvoření
malé testovací sítě, na které byly některé vlastnosti IPv6 ověřovány a hodnoceny. Tato část je
doprovázena podrobnými konfiguračními údaji, z nichž některé jsou součástí přílohy diplomové práce.
Další kapitolou praktické části je nástin budoucího možného přechodu celé sítě VŠE s uvedením
jednotlivých fází, alternativních řešení a hrubého časového odhadu. Na závěr celé práce je uvedena
shrnující kapitola se stručným zopakováním zjištěného a návrhy na možné navazující aktivity.
Na konci práce je uveden terminologický slovníček a přílohy, které obsahují doplňující
informace k hlavní stati práce.
Hlavní myšlenkou práce (a protokolu IPv6) je snaha řešit obtížné problémy současného
protokolu síťové vrstvy Internetu na komplexní a dlouhodobé bázi.
strana 4
Abstract
Internet as a contemporary global world-wide network is based on network protocol IP version
4. The objective of this diploma work is to examine current state of design, standardization,
implementation, usability and general knowledge of the new designed Internet protocol IP version 6
(IPv6). The purpose of thesis is to assort available information and knowledge into synoptic form and
use this knowledge to achieve more information by testing available implementations of the new
protocol. Another objective is to create a text that would make new protocol more understandable for
broader public. This is the reason why the work includes explanations that may be familiar for
experienced reader.
Theoretical part of thesis is done by achieving, processing and evaluating different information
from many different sources, especially English texts describing protocol standards. Another source of
information were the opinions of various professionals from commercial and academic institutions and
own knowledge of author. This knowledge was considerably extended during the main part of the
diploma work – practical testing of installation and implementation of the protocol in small laboratory
network. The testing brought many new facts. The objective of thesis can be achieved also through
author’s own ideas, thoughts and forecasts about further aspects and problems of the protocol. These
ideas are included in text and they are based right on practical tests.
The benefit of thesis is sustained survey of the problem area, which is not very well covered by
good literature (especially in Czech language). Thesis could be used as a reference assistant for
facilitating own practical tests of the interested reader. Even more sophisticated tests and
implementations could be based on conclusions of this diploma work. The next benefit could be the
creation of the Czech text that should facilitate the propagation of the new (but in future necessary)
protocol to uninformed people.
Thesis is divided into theoretical and practical part.
Theoretical part starts with short recapitulation of historical events that preceded the evolution
of the new protocol. The following technological part summarizes the characteristics and capabilities
of IPv6. Very important question is transition of the Internet from present IPv4 to future IPv6 protocol
and that is why I describe some of transition mechanisms in the next chapter. The following two
chapters summarize contemporary implementations existing on routers and end nodes in various
experimental and commercial networks. The successful transition to the new protocol depends also on
non-technological circumstances that are summarized in chapter about economic aspects of the new
protocol. The final chapter of theoretical part is outline of some (especially transition) problems of
IPv6 and very conservative prognosis of the future evolvement.
First chapter of the practical part deals with registration of IPv6 networks and address ranges
with emphasis on the network of the University of Economics in Prague, CZ. The following chapter
describes in detail the creation of small testing network, where were capabilities of IPv6 proved and
evaluated. This part is accompanied by configuration information. Detailed information about
configuring is included in annex of the diploma work. The next chapter is brief outline of possible
future transition of the network of University of Economics, divided into time periods with alternative
solutions. At the end of the whole thesis is complete summary with proposals of future IPv6 activities.
Text ends with terminological vocabulary and annexes, which includes subsidiary information
to main thesis.
The main idea this diploma work is to solve difficult problems of present protocol of the
network layer of the Internet on complex and longtime basis.
strana 5
Obsah
OBECNÝ ÚVOD ................................................................................................................................................... 9
PŘEDMLUVA ........................................................................................................................................................ 9
VYMEZENÍ TÉMATU PRÁCE A DŮVOD VÝBĚRU TÉMATU ....................................................................................... 9
STRUČNÁ CHARAKTERISTIKA SOUČASNÉHO STAVU PROBLÉMOVÉ OBLASTI ........................................................ 9
CÍL PRÁCE, SMYSL CÍLE ..................................................................................................................................... 10
ZPŮSOB A METODA DOSAŽENÍ CÍLE ................................................................................................................... 10
PŘEDPOKLADY PRÁCE ....................................................................................................................................... 10
OMEZENÍ PRÁCE ................................................................................................................................................ 11
KOMU JE MATERIÁL URČEN A JAK HO MÁ VYUŽÍT ............................................................................................. 11
TEORETICKÁ ČÁST
1.
HISTORICKÝ ÚVOD............................................................................................................................... 13
1.1.
O TÉTO KAPITOLE ................................................................................................................................ 13
1.2.
VZNIK PROTOKOLU IP A JEHO ROZŠIŘOVÁNÍ PO SVĚTĚ........................................................................ 13
1.2.1. Myšlenka odolné sítě...................................................................................................................... 13
1.2.2. Vznik přenosového protokolu......................................................................................................... 13
1.2.3. Komercionalizace Internetu........................................................................................................... 14
1.3.
NEDOKONALOSTI SOUČASNÉHO IPV4, PŘÍČINY VZNIKU HLEDÁNÍ NOVÝCH ŘEŠENÍ ............................. 15
1.3.1. Rozsah adresního prostoru ............................................................................................................ 15
1.3.2. Bezpečnost ..................................................................................................................................... 18
1.3.3. Multicast ........................................................................................................................................ 18
1.3.4. Kvalita služby ................................................................................................................................ 19
1.3.5. Mobilní zařízení, adresy a mobilita uzlu mezi sítěmi..................................................................... 19
2.
VLASTNOSTI IPV6.................................................................................................................................. 21
2.1.
O TÉTO KAPITOLE ................................................................................................................................ 21
2.2.
SPECIFIKACE A ZÁKLADNÍ HLAVIČKA PROTOKOLU.............................................................................. 21
2.3.
DOPLŇUJÍCÍ HLAVIČKY........................................................................................................................ 22
2.4.
VELIKOST PAKETU .............................................................................................................................. 23
2.5.
ADRESOVÁNÍ V IPV6........................................................................................................................... 24
2.5.1. Základní principy........................................................................................................................... 24
2.5.2. Zápis adres a prefixů sítí ............................................................................................................... 26
2.5.3. Členění adresy ............................................................................................................................... 27
2.5.4. Multicastové adresy ....................................................................................................................... 27
2.6.
AUTOMATICKÁ KONFIGURACE A OBJEVOVÁNÍ OKOLÍ ......................................................................... 28
2.7.
SMĚROVACÍ PROTOKOLY ..................................................................................................................... 29
2.8.
SERVISNÍ PROTOKOL ........................................................................................................................... 31
2.9.
PODPORA BEZPEČNOSTI....................................................................................................................... 32
2.10.
MOBILNÍ ZAŘÍZENÍ .............................................................................................................................. 33
2.11.
KVALITA SLUŽBY ................................................................................................................................ 34
2.12.
DNS – JMENNÉ SLUŽBY ....................................................................................................................... 35
2.13.
PROBLÉMY NÁVRHU ............................................................................................................................ 36
3.
PŘECHOD Z IPV4 NA IPV6 – INTEGRACE, KOEXISTENCE ........................................................ 37
3.1.
O TÉTO KAPITOLE ................................................................................................................................ 37
3.2.
PŘEDPOKLADY PŘECHODU .................................................................................................................. 37
3.3.
FORMY KOEXISTENCE A PŘECHODU .................................................................................................... 37
3.3.1. Duální protokol.............................................................................................................................. 37
3.3.2. Tunelování ..................................................................................................................................... 38
3.3.3. Překladače ..................................................................................................................................... 38
4.
STAV IMPLEMENTACÍ DNES A VÝHLED DO BLÍZKÉ BUDOUCNOSTI .................................. 41
4.1.
O TÉTO KAPITOLE ................................................................................................................................ 41
4.2.
IMPLEMENTACE V OPERAČNÍCH SYSTÉMECH ....................................................................................... 41
4.3.
IMPLEMENTACE NA SÍŤOVÝCH PRVCÍCH .............................................................................................. 42
4.4.
STAV APLIKACÍ ................................................................................................................................... 42
5.
POUŽITÍ VE SVĚTĚ A V ČR.................................................................................................................. 44
5.1.
O TÉTO KAPITOLE ................................................................................................................................ 44
5.2.
EXPERIMENTÁLNÍ A AKADEMICKÉ POUŽITÍ ......................................................................................... 44
5.2.1. 6bone ............................................................................................................................................. 44
5.2.2. CESNET......................................................................................................................................... 44
strana 6
5.2.3. Euro6IX, 6NET ..............................................................................................................................45
5.2.4. Jiné IPv6 projekty ..........................................................................................................................45
5.2.5. Poskytovatelé zadarmo ..................................................................................................................46
5.3.
KOMERČNÍ POUŽITÍ .............................................................................................................................46
5.3.1. Zahraničí .......................................................................................................................................46
5.3.2. Česká republika .............................................................................................................................47
6.
EKONOMICKÉ ASPEKTY .....................................................................................................................48
6.1.
O TÉTO KAPITOLE ................................................................................................................................48
6.2.
JAK SE MŮŽE ŘEŠENÍ UPLATNIT V PRAXI ..............................................................................................48
6.3.
JAK OVLIVNÍ TRH ICT A EKONOMIKU ..................................................................................................48
6.4.
JAK OVLIVNÍ FIRMY – ISP A JEJICH ZÁKAZNÍKY ..................................................................................49
6.5.
JAK OVLIVNÍ KONCOVÉ UŽIVATELE .....................................................................................................50
6.6.
ANALÝZA SWOT IPV6 .......................................................................................................................51
6.6.1. Silné stránky (S).............................................................................................................................51
6.6.2. Slabé stránky (W)...........................................................................................................................51
6.6.3. Příležitosti (O) ...............................................................................................................................51
6.6.4. Hrozby (T)......................................................................................................................................51
6.7.
ZÁVĚRY EKONOMICKÉ ČÁSTI ..............................................................................................................52
7.
PROBLÉMY A PROGNÓZY...................................................................................................................53
7.1.
O TÉTO KAPITOLE ................................................................................................................................53
7.2.
PROBLÉMY PŘECHODU A NÁSTIN MOŽNÝCH ŘEŠENÍ ............................................................................53
7.2.1. Psychologické předpoklady přechodu ...........................................................................................53
7.2.2. Směrovače, páteřní a místní sítě ....................................................................................................53
7.2.3. Koncové uzly a aplikace ................................................................................................................55
7.3.
PROGNÓZA ..........................................................................................................................................56
7.3.1. Rozšiřování IPv6............................................................................................................................56
7.3.2. Uživatelský a tržní úspěch..............................................................................................................57
PRAKTICKÁ ČÁST
8.
REGISTRACE SÍTÍ ..................................................................................................................................60
8.1.
O TÉTO KAPITOLE ................................................................................................................................60
8.2.
PODMÍNKY A PRŮBĚH REGISTRACE......................................................................................................60
8.2.1. Obecné skutečnosti a zásady..........................................................................................................60
8.2.2. Přidělování v praxi ........................................................................................................................61
8.3.
STAV REGISTRACE PRO VŠE................................................................................................................63
9.
ZKOUŠKA IMPLEMENTACE A PŘIPOJENÍ DO INTERNETU V MALÉ SÍTI............................64
9.1.
O TÉTO KAPITOLE ................................................................................................................................64
9.2.
VÝCHOZÍ SITUACE ...............................................................................................................................64
9.2.1. Cíle zkušební sítě ...........................................................................................................................64
9.2.2. Popis zkušební sítě .........................................................................................................................64
9.2.3. Tvorba zkušební sítě.......................................................................................................................66
9.3.
PRŮBĚH A VÝSLEDKY TESTOVÁNÍ .......................................................................................................68
9.3.1. Jmenné služby (DNS) .....................................................................................................................68
9.3.2. Tunelovací mechanismy.................................................................................................................70
9.3.3. Směrování ......................................................................................................................................70
9.3.4. Služby protokolu http .....................................................................................................................74
9.3.5. Služby vzdáleného přihlášení.........................................................................................................76
9.3.6. Služby přenosu souborů .................................................................................................................77
9.3.7. Poštovní služby ..............................................................................................................................78
9.4.
SHRNUTÍ A ZÁVĚR TESTOVÁNÍ.............................................................................................................79
9.4.1. Zhodnocení provozu uzlů ...............................................................................................................79
9.4.2. Další možnosti výzkumu.................................................................................................................80
10. NÁSTIN OSTRÉHO PŘECHODU V SÍTI VŠE.....................................................................................82
10.1.
O TÉTO KAPITOLE ................................................................................................................................82
10.2.
POPIS SÍTĚ ...........................................................................................................................................82
10.3.
MOTIVY PŘECHODU.............................................................................................................................82
10.4.
NÁSTIN POSTUPU PŘECHODU ...............................................................................................................83
10.4.1.
Počátek......................................................................................................................................83
10.4.2.
Pro první uživatele ....................................................................................................................83
10.4.3.
Přechod celých podsítí ..............................................................................................................84
strana 7
10.4.4.
Přechod celých lokalit............................................................................................................... 84
10.4.5.
Dokončení ................................................................................................................................. 85
10.4.6.
Časový plán............................................................................................................................... 85
11. SHRNUTÍ OBSAHU PRÁCE................................................................................................................... 86
11.1.
O TÉTO KAPITOLE ................................................................................................................................ 86
11.2.
SHRNUTÍ VÝSLEDKŮ Z TEORETICKÉ ČÁSTI .......................................................................................... 86
11.2.1.
Proč vznikl IPv6........................................................................................................................ 86
11.2.2.
Nejvýznamnější vlastnosti ......................................................................................................... 87
11.2.3.
Soužití s IPv4 a přechod na novou verzi ................................................................................... 88
11.2.4.
Implementace a použití ve světě dnes........................................................................................ 88
11.2.5.
Ekonomické aspekty .................................................................................................................. 89
11.2.6.
Možný úspěch?.......................................................................................................................... 90
11.3.
SHRNUTÍ VÝSLEDKŮ Z PRAKTICKÉ ČÁSTI ............................................................................................ 90
11.3.1.
Současný stav registrace adres ................................................................................................. 90
11.3.2.
Testování v praxi....................................................................................................................... 91
11.3.3.
Budoucí přechod v síti VŠE....................................................................................................... 91
11.4.
ZHODNOCENÍ VYUŽITELNOSTI DOSAŽENÝCH VÝSLEDKŮ .................................................................... 92
11.4.1.
Další náměty na řešení problémové oblasti .............................................................................. 92
11.5.
MŮJ PŘÍNOS K ŘEŠENÉ PROBLEMATICE ............................................................................................... 93
11.6.
ZÁVĚREM ............................................................................................................................................ 94
12. LITERATURA, POUŽITÉ ZDROJE...................................................................................................... 95
13. SLOVNÍČEK POJMŮ A ZKRATEK...................................................................................................... 97
14. SEZNAM OBRÁZKŮ A TABULEK ..................................................................................................... 100
PŘÍLOHY .......................................................................................................................................................... 101
NÁVRH SÍŤOVÝCH PROTOKOLŮ V SÍTI ARPANET/INTERNET - TCP/IP NEBO OSI? ........................................ 101
INSTITUCE A SPRÁVA INTERNETU .................................................................................................................... 102
VERZE PROTOKOLU IP – PROČ PRÁVĚ 6? ......................................................................................................... 102
PŘEDPOKLADY A OČEKÁVÁNÍ OD PROTOKOLU NOVÉ GENERACE ..................................................................... 104
OČEKÁVÁNÍ OD IPV6....................................................................................................................................... 104
PRACOVNÍ SKUPINY IETF, KTERÉ SE ZÁLEŽITOSTMI KOLEM IPV6 ZABÝVAJÍ .................................................. 106
Jádrová pracovní skupina.......................................................................................................................... 106
Přechod ze stávajícího protokolu............................................................................................................... 106
Dopad na IETF a ne IETF standardy ........................................................................................................ 107
DALŠÍ VYBRANÉ NOVINKY IPV6...................................................................................................................... 108
KONFIGURAČNÍ SOUBORY POUŽITÉ PŘI PRAKTICKÉM TESTOVÁNÍ - DNS......................................................... 109
VÝPIS SÍŤOVÝCH ROZHRANÍ, SMĚROVACÍCH TABULEK A DOSTUPNOSTI VYBRANÝCH UZLŮ Z POČÍTAČŮ
V TESTOVACÍ SÍTI............................................................................................................................................. 110
Počítač ASTRA........................................................................................................................................... 110
Počítač STROM ......................................................................................................................................... 111
Počítač BSD............................................................................................................................................... 112
TEXT DOPISU POSKYTOVATELŮM PŘIPOJENÍ A MOBILNÍM OPERÁTORŮM ......................................................... 114
strana 8
Obecný úvod
Předmluva
Komunikace je jedním ze základních projevů života – výměna informací s okolím je nutná
podmínka existence pro jakýkoliv organismus. Týká se to i člověka, který odpradávna komunikuje a
hledá možnosti, jak vzájemnou komunikaci usnadnit a odstranit překážky, které jí brání. Lidské
dorozumívání je na poměrně vysoké úrovni jak svým obsahem, tak i prostředky, které využívá.
Obě složky komunikace se rozvíjí i dále. Jednou z posledních významných změn je využití
elektronických počítačových sítí pro výměnu informací. Otevřely se tím velké možnosti pro distribuci
dat, informací a znalostí. Změnu pocítil každý z nás masovým rozvojem Internetu počátkem 90. let
minulého století, zejména díky jeho úspěšné komercionalizaci, vstupu řady různých subjektů na něj a
vytvoření řady užitečných služeb.
Základy Internetu, neboli sítě založené na rodině protokolů Transmission Control Protocol/
Internet Protocol (TCP/IP), byly položeny již v šedesátých letech. Návrh protokolu IP se ukázal jako
velmi životaschopný i ve velmi rozlehlých sítích a po dlouhou dobu nepotřeboval větších úprav. Svět
se ovšem vyvíjí ve všech směrech a nedávno se ukázalo, že je třeba provést změny i v této oblasti.
Vymezení tématu práce a důvod výběru tématu
Diplomová práce se zabývá návrhem, vlastnostmi, možnostmi, problémy a stavem
implementace nové verze internetového protokolu - IPv6. Jde o návrh nového protokolu síťové vrstvy
Internetu, dnes bezesporu nejrozšířenější a nejpoužívanější počítačové sítě. V pojetí architektury IS/IT
(informačního systému/informačních technologií) se pohybuji v oblasti technologické architektury
informačního systému (IS), na spodní úrovni základních zdrojů informačního systému a v softwarové
dimenzi (sw).
Rozsah záběru práce jsem stanovil jako základní přehled důležitých aspektů nového protokolu –
od historie a důvodů, proč se někdo začal návrhem nové verze zabývat, přes vlastnosti a možnosti
protokolu, které prakticky ověřím vlastními pokusy, až po pohled do praxe na jeho reálné využití
s důrazem na ekonomické účinky, které může vyvolat. Jde o relativně nový prostředek a k jeho
zhodnocení je nezbytná i prognóza - můj vlastní odhad budoucího vývoje a možnosti úspěchu
navržených řešení jsem uvedl v závěru teoretické části.
Druhou, praktickou částí práce, je jednoduché použití stávajících implementací IPv6 v praxi,
zahrnující registraci u odpovědných autorit, tvorba zkušební IPv6 sítě a velmi základní nástin
možného budoucího přechodu stávající IPv4 sítě na nový protokol u větší instituce. V této části práce
očekávám zjištění nejvíce nových poznatků a použitelný přínos pro další aktivity kolem IPv6.
Důvodem výběru tématu je aktuálnost problémů, které stávající verze IP (IPv4) má, a které je
potřeba v dohledném časovém horizontu vyřešit. Tím, že je Internet globální veřejnou sítí, jsou
problémy o to větší a o to naléhavěji vyžadují řešení. Pokud by současné potíže s použitím Internetu
nebyly řešeny, mohl by být potlačen pozitivní síťový efekt Internetu, umožňující ve svém důsledku
vzniknout novým hodnotám. Internetový protokol verze 6 je jedním z možných východisek a zdá se
být řešením s velkou šancí na úspěch a další rozvoj, protože vedle řešení stávajících problémů nabízí i
nové možnosti a služby.
Dalším důvodem tématu je fakt, že se jedná o téma v české a slovenské literatuře jen málo
zpracované (výjimkou budiž kvalitní dokumenty RNDr. Pavla Satrapy z Liberecké technické
univerzity). Úvodní přehled k IPv6 jako velmi pravděpodobnému nástupci stávajícího IP protokolu by
mohl být užitečný, a to nejen pro techniky, správce sítí, ale i pro taktická a strategická rozhodnutí
v oblasti síťové infrastruktury firem.
Stručná charakteristika současného stavu problémové oblasti
Počet uzlů a sítí do Internetu zapojených každoročně roste, zdaleka se neblíží svému nasycení a
požadavky kladené na služby sítě ze stany uživatelů a poskytovatelů služeb stále rostou. Některé tyto
požadavky ovšem není snadné splnit, protože pro ně nebyla současná verze protokolu IPv4 přímo
navržena. Je tedy nutno k jejich řešení přistupovat komplikovanější cestou, než kdyby je návrh
protokolu bral v úvahu a implementace by je podporovaly již v základním provedení.
Prvním problémem je nedostatek číselných adres počítačů a sítí, které je možné přidělovat.
Původní 32-bitový rozsah byl dlouho dostatečný a zdál se dokonce nevyčerpatelný, nicméně současná
strana 9
popularita IP sítě je taková, že se nové adresy musí přidělovat velmi opatrně, což omezuje použití
některých žádoucích služeb.
S rozvojem mobility uživatelů přišla i potřeba být dosažitelný z různých míst pod stále stejnou
adresou. Původní koncept IP s mobilitou počítal v omezené míře, později pak na úrovni celých sítí –
úroveň jednotlivých počítačů je nutno řešit zvláštními nástroji.
Komerční využívání Internetu přineslo také nasazování aplikací (např. přenos zvuku a obrazu
v reálném čase), které potřebují mít ze strany síťové infrastruktury zajištěné určité parametry přenosu
a tyto zákazníky zaplacené služby je potřeba umět garantovat. Přenosová kapacita sítě je sice stále
rostoucí, nicméně je konečná a je tedy potřeba klasifikovat a třídit probíhající provoz a datovou zátěž.
Důležitá data specifických aplikací musí dorazit včas, a poskytovatelé připojení k Internetu (ISP,
Internet Service Provider) musí mít nástroj pro účtování svých klientů – mimo jiné podle priorit
přenášených dat.
A se spolehlivostí souvisí i bezpečnost přenášených dat – podpora šifrování či autentizace toku
dat není součástí IP standardu, ale bývá řešena separátně (pokud vůbec). Požadavky na větší
důvěryhodnost a bezpečnost sítí se objevují v souvislostí s elektronickým obchodováním.
Při zpracování práce jsem vycházel ze zjišťování současného stavu IP sítí. Není překvapující
stávající převaha protokolu IPv4, který však vykazuje výše zmíněné nedokonalosti.
Cíl práce, smysl cíle
Smyslem práce je poskytnout čtenáři základní představu o nejdůležitějších možnostech nového
internetového protokolu v porovnání s předchozí verzí. Zájemce by měl získat technické informace
teoretického a praktického charakteru a zmapování současného stavu zavádění protokolu do praxe
v České republice a ve světě. Měl by také získat základy pro možné vlastní zkušební aktivity s IPv6
(plynoucí zejména z praktické části práce).
Práce by také měla přispět náměty, důvody a prognózami při uvažování o přechodu na nový
protokol z ekonomického hlediska. V neposlední řadě by mohla pomoci zvýšit všeobecné povědomí o
možnostech a reálnosti nasazení IPv6 obecně.
Způsob a metoda dosažení cíle
Cíle práce jsem dosáhl studiem informačních zdrojů (hlavním zdrojem je sada navržených a
schválených RFC dokumentů a literatury, informace o řešení rozhodujících firem z oboru, informace z
konferencí), anketou v českých telekomunikačních firmách, vlastní zkušební činnost při tvorbě
jednoduché IPv6 sítě, konzultacemi s vedoucím práce a dotazy odborníků z praxe. Informace získané
z cizích zdrojů jsem roztřídil, zhodnotil dle aktuálnosti, relevance k tématu, zajímavosti a odborné
úrovně, doplnil vlastními názory, znalostmi a zkušenostmi a ve zvolené struktuře a objemu uspořádal
do jednotlivých podtémat diplomové práce tak, aby splňovaly mnou stanovené cíle.
Záměrem diplomové práce bylo podat výklad části IP problematiky jak pro laickou, tak pro
odbornou veřejnost. Z tohoto důvodu jsou zejména v úvodu práce uvedeny shrnující pasáže, které
může informovaný čtenář už znát. Soudím však, že pro uvedení do záležitostí kolem IPv6 je dobré tyto
skutečnosti krátce zopakovat.
Některé informace jsou v práci z důvodu zdůraznění a usnadnění pochopení problému uvedeny
na více místech – například v odborné teoretické pasáži a při aplikaci v praktické pasáži. Nejde o
prosté zopakování textu, ale jiný pohled na tutéž záležitost podle potřeby použití. Záměrem je umožnit
čtenáři pochopení důležitých skutečností různými způsoby.
Práci jsem zpracovával v časovém období od června 2001 do dubna 2002, přičemž informace
jsou aktualizovány právě k dubnu 2002.
Předpoklady práce
Předpokladem platnosti práce a závěrů v ní obsažených je neutuchající zájem uživatelů o služby
elektronických počítačových sítí (zejména mobilních), rostoucí role informatiky v podnikání a
obchodu, požadavek důvěry v elektronické podnikání a stálý tlak na celosvětovou jednodušší výměnu
informací. To implikuje i existenci počítačové sítě typu Internet na protokolu IP i v několika
nejbližších letech a nutnost jejího dramatického rozvoje, včetně řešení otázek škálovatelnosti,
dostupnosti, bezpečnosti a mobility. Troufám si říci, že výše uvedené předpoklady budou při klidném
ekonomickém prostředí bez větších výkyvů ve společnosti splněny ve velké části světa.
strana 10
Konkrétnějším předpokladem práce je existence jistých problémů současného IP protokolu (o
čemž panuje všeobecná shoda) a nutnosti jejich řešení v krátkém čase a celosvětově shodně.
Omezení práce
Omezení práce vychází z mých možností a schopností a mně dostupných informačních zdrojů.
Nejvíce se projeví v ekonomické a prognostické části práce, kde je velkou nevýhodou malý počet (ve
srovnání s IPv4) existujících implementací nového protokolu (navíc primárně v akademické sféře),
takže mnou vyvozené závěry nelze použít jako konkrétní argument pro rozhodování, ale jen jako další
pohled a názor.
Omezení v teoretické části vychází z rychlého rozvoje poznatků a standardů v této oblasti. Ne
všechny návrhy protokolů a vlastností jsou standardizovány, ne všechny se budou ve finální verzi IPv6
vyskytovat tak, jako se vyskytují dnes a jak o nich píši. Může dojít k odchylkám a případný čtenář by
si měl u zatím neustálených dokumentů (jsou označeny) zkontrolovat jejich poslední verzi vůči
odchylkám. Jádro a obklopující skupina návazných služeb je již nicméně ustálena delší dobu a na
principech by se nemělo měnit nic.
Zajímavou a potřebnou další aktivitou by mohlo být trvalé testování větší sítě a širší škály
platforem, než jsem měl při praktických pokusech k dispozici. To je však mimo záběr této diplomové
práce a mimo současné možnosti hardware na VŠE (je využito provozně jinak). Nicméně je to možný
námět pro budoucnost.
Vhodným doplněním práce, které bohužel není obsaženo, by mohlo být konkrétní provedení
projektu implementace (přechodu) IPv6 ve větší síti, tak, jak je nastíněno na konci praktické části
práce. Při teoretickém uvažování jsem se i při nejlepší vůli mohl dopustit několika opomenutí nebo
nepřesností, které by v praxi vyšly najevo a bylo by nutno návrh upravit. Z pochopitelných důvodů
však testovací síť takového rozsahu neexistuje.
Komu je materiál určen a jak ho má využít
Diplomová práce je určena širokému okruhu odborníků laiků z oblasti informačních a
komunikačních technologií:
- Na nejdetailnější a nejspodnější úrovni (ve smyslu architektur IS/IT) si ji může přečíst návrhář,
implementátor nebo správce sítí, který se z ní dozví technologické podrobnosti protokolu a
možnosti praktického použití ve stávajících a nových sítích.
- Zájemci o počítačové sítě z řad odborné i laické veřejnosti získají z diplomové práce základní
přehled o nových navržených službách. Dozví se, proč se k některým změnám muselo přistoupit,
co se bude muset změnit a co jim to umožní.
- A konečně představitelé IT managementu budou po přečtení mít rámcovou představu o
možnostech úspěchu IPv6, možných ekonomických přínosech, smysluplnosti přechodu jejich sítí
na nový protokol a částečně i o možnosti rozvoje jejich infrastruktury IS/IT.
Práce se sice primárně zabývá novým internetovým protokolem IPv6, nicméně si myslím, že
najde užitek i v případě volby jiného východiska z problémů stávajících rozlehlých sítí. Práce by
mohla sloužit například jako základní východisko při návrhu dokonalejšího řešení nebo jako
referenční zdroj v případě porovnání s podobnou studií o alternativách. V neposlední řadě by pak její
ekonomická část při určitém zobecnění mohla být sylabem pro uvažování o nových síťových řešeních
obecně.
U každého čtenáře práce se předpokládá minimální znalost síťové problematiky, základní
znalost principů fungování IP protokolu a zájem o novinky.
strana 11
TEORETICKÁ ČÁST
strana 12
1. Historický úvod
1.1.
O této kapitole
V této kapitole diplomové práce je uvedeno, které relevantní události předcházely vzniku IPv6
v podobě, ve které se vyskytuje dnes. Vývoj začíná v šedesátých letech minulého století na
ministerstvu obrany a univerzitách USA, samotný IP protokol vzniká v letech sedmdesátých.
V průběhu osmdesátých let stále více nasazovaný protokol prožívá obrovský rozmach používání
v letech devadesátých, což je nutně spojeno s novými požadavky na něj a s projevením se jeho
nedokonalostí. Na jejich řešení vzniklo několik paralelních pracovních skupin, jejichž výsledky daly
v polovině devadesátých let vzniknout návrhu IPv6. Zdrojem mi byly zejména prameny [2,24,26].
1.2.
Vznik protokolu IP a jeho rozšiřování po světě
1.2.1. Myšlenka odolné sítě
Počátkem šedesátých let se začaly objevovat první myšlenky (převážně v USA) na vytvoření
sítě, která by navzájem propojovala nejdůležitější vojenské, vládní a vědecko-výzkumné počítače.
Mělo jít o síť decentralizovanou, která bude fungovat i v případě výpadku či zničení některého z uzlů.
Současně mělo platit, že všechny uzly měly být rovnocenné, každý z nich měl mít možnost vysílat i
přijímat zprávy. Dalším cílem sítě mělo být propojení superpočítačových kapacit výpočetních
středisek a možnost vykonávat úlohy na dálku.
Počítačové komunikace (přenosu textu a binárních dat) bylo do té doby velmi málo a neměla
síťový charakter, šlo spíše o dvoubodové přenosy, založených zejména na přepínání okruhů. Jde o
koncept vyhrazení celé přenosové cesty mezi dvěma body předem, které se pak celá používá výhradně
pro data jednoho přenosu. Cesta se v průběhu přenosu nemění a není možné dílčí spoje využít pro jiné
přenosy, i když se dočasně data nepřenáší.
Z požadavků na novou síť plynulo, že bude třeba zvolit takovou technologii, která bude více
nezávislá na předem zvolené přenosové cestě a bude schopna udržet i běžící komunikaci, pokud dojde
k poruše mezilehlých uzlů. Několik na sobě nezávislých výzkumných týmů rozvinulo na začátku
šedesátých let myšlenku přepínání paketů, která svým založením myšlenku sítě bez centrální autority
podporuje. Přenášená data se rozdělí do malých jednotek, které putují sítí společně s dalšími datovými
přenosy bez nutnosti sestavit před přenosem vyhrazený okruh.
Americké ministerstvo obrany přišlo v druhé polovině šedesátých let s požadavkem vybudovat
síť založenou na tomto principu. Dostala označení ARPANET a v září roku 1969 došlo k prvním
datovým přenosům mezi čtyřmi americkými univerzitami. Do roku 1971 se síť rozšířila na univerzity
po celém americkém kontinentu. Ukázala se být úspěšnou a rostl zájem o připojení k ní. Hlavním
využitím této sítě byla elektronická pošta.
1.2.2. Vznik přenosového protokolu
V ARPANETu poprvé spatřily světlo světa přenosové protokoly založené na přepínání paketů,
které se používaly dlouhou dobu a některé z nich existují dodnes. V sedmdesátých letech byla proto
navržena robustnější sada („rodina“, anglicky „stack“) protokolů, založená na standardu Transmission
Control Protocol (TCP). Ten byl navržen pro komunikaci koncových uzlů.
Tehdejší směrovače (nazývané „gateways“, brány) však nebyly dostatečně výkonné a řízení
datového provozu na transportní úrovni, jako kdyby byly koncovými uzly, pro ně bylo zbytečnou
zátěží. Aby se komunikace zbytečně nezpomalovala, byly činnosti a odpovědnosti TCP rozděleny do
dvou protokolů sousedních vrstev (v terminologii modelu OSI: do síťové a transportní). Jednodušší
síťový protokol, nezaručující spolehlivost, určený pro komunikaci uzlů se směrovači a mezi směrovači
navzájem, dostal název Internet Protocol (IP). TCP zůstalo jako nadstavba zajišťující spolehlivou
komunikaci, pro nepotvrzovaný přenos byl vytvořen transportní protokol UDP.
Za posledních dvacet let se protokoly změnily jen málo – jádro zůstalo stejné a rozšíření se
týkala spíše doplňků, které řešily některé neočekávané problémy. Dvojice standardů TCP/IP byla
ovšem navržena natolik robustně, že problémy byly malé a změny nemusely být tak závažné, aby
nemohly být prováděny i v běžícím prostředí a jen v částech sítě.
TCP/IP se stalo jedinou přenosovou platformou, která získávala na popularitě implementací do
jádra tehdejší verze (4.2) univerzitního BSD Unixu. I díky rozvoji a zvyšování dostupnosti technologií
strana 13
pro lokální sítě (Ethernet) se k páteři ARPANETu připojovaly další a další uzly. Po roce 1983 byla
překročena hranice 1000 připojených uzlů, v roce 1987 hranice 10 000, o dva roky později již 100 000
a rovného milionu uzlů dosáhla roku 1992. V roce 1986 vznikla v USA další páteřní síť NSFNET
založená na protokolech TCP/IP, propojující výzkumná superpočítačová střediska. Postupně přebírá
páteřní roli ARPANETu a k této páteřní síti už vznikali první poskytovatelé síťových služeb nižší
úrovně. Provoz ARPANETu byl postupně omezován a v roce 1990 zcela ukončen.
počet uzlů
1.2.3. Komercionalizace Internetu
Až do roku 1993 byla síť NSFNET vedena na nekomerční bázi. Jeho rostoucí popularita i
v neakademické sféře přitahovala velké telekomunikační firmy k myšlence postavit a provozovat
vlastní páteřní sítě a využívat je k výdělečným účelům i pro podniky a jednotlivce. V roce 1994 došlo
k výstavbě propojovacích bodů mezi začínajícími IP sítěmi různých provozovatelů a páteří NSFNET,
stavbě nových páteřních spojů (teď už z iniciativy soukromého sektoru) a dohodám o směrovacích
pravidlech a protokolech.
I tato změna, mající za následek exponenciálně rostoucí počet připojených uzlů proběhla bez
výraznějších změn v IP protokolu. Internet se od té doby decentralizovaně a rychle rozrůstal po všech
kontinentech (Československo bylo připojeno linkou do rakouského Linze v roce 1992).
Pojem „Internet“, které jsem zatím přesněji nedefinoval, se tedy používá pro označení rozsáhlé,
globální a otevřené informační metasítě (tj. sítě sítí) vzniklé postupným vývojem popsaným výše. V
užším slova smyslu pak Internet je soustava registrovaných sítí, schopných vzájemně si vyměňovat
pakety protokolu IP. Síť je víceúrovňová, nejčastěji se používá rozdělení na páteřní, sítě střední
velikosti a přístupové sítě, ke kterým se připojují koncoví uživatelé. Každá má trochu jiný charakter a
účel, ale všechny využívají stejného síťového a transportního protokolu.
Standardními službami postavenými nad protokoly TCP/IP v první fázi Internetu byly
elektronická pošta, přenos souborů File Tranfer Protocol (FTP) a telnet. Pošta je důležitá i dnes,
nicméně další dvě služby byly od devadesátých let postupně zastiňovány jinou, dnes zdaleka
nejpopulárnější – WWW.
Myšlenka služby World Wide Web na protokolu HTTP se poprvé objevila v roce 1989 ve
švýcarském středisku pro jaderný výzkum CERN, jeho první prototyp byl předveden roku 1990 a o tři
roky později začal prudký nárůst obliby. Troufl bych si odhadnout, že právě vznik WWW přilákal
k Internetu rozhodující část uživatelů a dnes je přenos dat protokolu HTTP dominantní součástí
síťového provozu na světě.
Až do roku 1993 zůstával Internet doménou vědeckých a akademických pracovišť. Poté se na
něm ale začaly ve velkém objevovat komerční firmy a informační služby zaměřené na běžné uživatele.
Internet se po tomto roce stal velmi rychlým vývojem v mnoha zemích běžnou součástí každodenního
života. Rozmanitost služeb v Internetu roste, objevují se požadavky na multimediální přenosy.
Přenosové rychlosti médií stále rostou do řádů terabitů (v páteřních sítích). Počet uživatelů roste
exponenciální řadou, na
Vývoj počtu uzlů v Internetu v letech 1991-2002
začátku roku 1994 byly
připojeno 2,5 milionu
160000000
uzlů, v roce 1998 40
140000000
milionů uzlů, v první
120000000
polovině roku 2000 už 80
100000000
milionů. V březnu 2002 už
80000000
tento počet dosáhl 145
60000000
milionů a zatím není
40000000
patrná fáze nasycení.
20000000
strana 14
01
X.
00
X.
99
X.
98
X.
97
X.
96
X.
95
X.
94
X.
93
X.
92
X.
X.
Obrázek 1: Graf počtu
uživatelů Internetu podle
[34].
91
0
zdroj: Internet Software Consortium (www.isc.org)
Síť používají k poskytování určitých služeb i státní instituce. Uživatel tak má hypoteticky
možnost číst denní tisk, nakupovat, bavit se, být ve styku s bankou a pracovat na dálku z domova. Ne
vždy to lze bezproblémově realizovat, důvody jsou jak technické (například nízká úroveň
bezpečnosti), tak i netechnické (například náklady na připojení a práci). Snahou zúčastněných institucí
je technické problémy odbourávat a řešit – například návrhem nové verze síťového protokolu.
1.3.
Nedokonalosti současného IPv4, příčiny vzniku hledání nových řešení
I přes dobře promyšlený a lehce nadčasový návrh IP protokolu, který celosvětové rozšíření
umožnil, má jeho specifikace slabá místa. Jde zejména o oblasti, které souvisí s komerčním využitím,
multimediálními aplikacemi a mobilními zařízeními. O těch ovšem autoři v době vzniku nemohli nic
vědět, stejně tak jistě nepředpokládali, že bude Internet přístupný téměř komukoliv a že počet
připojených uzlů poroste exponenciální řadou. Co je IPv4 nejčastěji vytýkáno?
1.3.1. Rozsah adresního prostoru
Adresa, neboli unikátní označení uzlu připojeného k síti, je ve stávajícím IP protokolu o rozsahu
32 bitů, což dává teoreticky možnost připojit a označit 2^32 počítačů (přes čtyři miliardy). Tvůrci ale
v záměru tolik uzlů připojit neměli. Skutečný počet počítačů, které je možné připojit, je nižší, protože
některé adresy mají určeno speciální použití z důvodu dalšího rozčlenění adresy a přiřazení různého
významu jejím částem.
32-bitová adresa je totiž rozdělena na část označující síť (prefix) a na část označující počítač
v dané síti. Mechanismus směrování (routingu) paketu mezi sítěmi musí zajistit skutečnost, že
libovolné dva počítače na Internetu si mohou předávat data, i když leží v úplně jiných sítích, které
spolu nesousedí. Není zvládnutelné udržovat cestu ke každému uzlu zvlášť a při směrování se proto
pracuje pouze s adresou celé sítě a podle ní směrovače volí další cestu paketu (to je princip, na kterém
je založena síťová vrstva - na rozdíl od spojové). Pakety se posílají stejným směrem podle stejné
síťové adresy a na adresu koncového uzlu se hledí až paket dorazí do cílové sítě.
A aby tedy byl celý proces směrování rozumně zvládnutelný (aby jednotlivých cest pro stejný
směr nebylo moc), jsou uzlům v sítích přidělovány adresy po blocích, takže se určitá část adres
spotřebuje na režii spojenou s fragmentací adresního prostoru.
Původně se adresy přidělovaly ve třech třídách A,B a C, každá o různém počtu připojitelných
uzlů. Třídy se mezi sebou liší délkou části 32 bitové adresy, která označuje síť a uzel. V síti třídy A,
kde síť označuje prvních 8 bitů, zbývá 24 bitů na adresu uzlu a bylo tedy možno připojit přes 16,7
milionu počítačů. V B síti je označení sítě dlouhé 16 bitů, uzel může pro své označení použít 16 bitů,
což je použitelných 65534 uzlů (první a poslední adresa má speciální význam). V nejmenší síti C
(kterých je ale zase nejvíc, protože šíře jejich označení je 24 bitů) můžeme přidělit 254 síťových
rozhraní (interface). Třídy se tedy od sebe liší pomyslnou bitovou „hranicí“, kde končí síťová adresa a
kde začíná adresa uzlu. Kde se hranice nachází (do jaké třídy adresa patří), se dalo rozeznat z prvních
bitů adresy – zbylé adresy zůstaly rezervované pro budoucí použití (našly jej později zejména v
multicastu).
0
A 0
B
10
C
110
třída
adresy
adresa uzlu (24 bitů)
síť (8 bitů)
adresa sítě (16 bitů)
adresa sítě (24 bitů)
adresa uzlu (16 bitů)
uzel (8 bitů)
počáteční bitová
kombinace
Obrázek 2: Původní třídy IP adres
strana 15
V době návrhu IP protokolu se zdálo, že 32 bitů ve třech třídách tvoří dostatečnou rezervu pro
všechny možné konfigurace a velikosti budoucích jednotlivých připojených sítí a i sítě jako celku.
Rozmach a celosvětovost Internetu, tak jak ji známe dnes, ale nikdo nečekal. Ukázalo se, že dělení IP
adresy po celých osmicích bitů není příliš jemné. Protože počítačová síť má většinou jiný počet uzlů
než oněch ideálních 16,7 milionu, 65534 nebo 254, určitá část adresního prostoru zůstávala nevyužita.
Tyto adresy nebylo možno z důvodu směrování použít jinde a dále zmenšovaly počet možných
připojitelných uzlů. Při návrhu sítě si také správci ponechávali určitou rezervu pro budoucí rozšiřování
a změny sítě – a žádali o větší počet adres, než byl aktuální počet uzlů.
Počet dostupných C adres (který jsou vzhledem k velikosti nejužívanější) se ukázal při expanzi
zájmu o Internet jako malý [22]. Bohužel ale nebylo možno přidělovat části dosud volných A a B
bloků různým novým sítím. Směrovače by totiž nevěděly, do které z těchto sítí pakety posílat (protože
prefix, síťová část adresy, by byla stejná pro obě dvě, i když by byly pravděpodobně dosažitelné po
jiných přenosových spojích). Přidělení dosud volných A a B bloků malé síti by bylo velkým plýtváním
– sítí A a B je málo k dispozici, ale mají v sobě mnoho volného místa.
Zdálo se, že slibný rozvoj sítě, která má obrovský potenciál, bude přidušen technickými
omezeními a zbytečně se vytvoří restrikce, které nejsou žádoucí – a které by nemusely být, pokud by
se lépe navrhl adresní prostor. Výhody z toho „být na síti“ ovšem byly a jsou tak veliké, že se začala
hledat řešení, která by dovolila stávající adresový prostor lépe využít a umožnila připojovat nové
účastníky a uzly bez omezení.
Jedním z řešení je navrhnout zcela novou verzi protokolu, která by prodloužila délku adresy.
Neboli – pokud už se musí do návrhu protokolů z důvodu nějakého problému zasahovat, raději jej
vyřešme důkladně a úplně s výhledem na delší čas, ať se za pár let nemusí řešit problémy, které se
vynořují už dnes. Na tomto základu se začal tvořit na přelomu osmdesátých a devadesátých let IP
protokol nové generace, IPng. Nicméně v případě důkladného nového návrhu, ve kterém se aplikují
všechny znalosti a poznatky současné doby a řeší se i méně závažné problémy komplexně, nutně
nastává problém se zpětnou kompatibilitou s původním protokolem.
S postupem času se ale podařilo vyvinout několik doplňkových mechanismů, které pomohly na
bázi stávajícího IPv4 (a to nejen primárně v počtu volných sítí a adres). Obtížná tvorba a přechod na
zcela nový protokol se proto nezdály být tak akutní. Je pochopitelně jednodušší implementovat
doplněk ke stávajícím standardům, než implementovat věci zcela nové.
O jaké doplňky šlo? Sesterské technologie CIDR (Classless Inter Domain Routing) a VLSM
(Very Large Subnet Masks) umožnily zjemnit striktní pojetí adresních tříd. Ty je možné u novějších
implementací směrovacích protokolů úplně opustit a stanovit bitovou délku adresy sítě a uzlu
libovolně (s respektováním celkového součtu 32 bitů) a přizpůsobit tak velikost adresního prostoru co
nejlépe na míru své síti. Lze například rozdělit C síť na několik menších podsítí a použít je na úplně
jiných místech, případně více C sítí spojit snadno do jediné. Dělit lze i dříve celistvé veliké A a B sítě
(např. A síť 62.0.0.0) na mnoho použitelnějších sítí menších.
Místo, kde se pomyslná dělící část v adrese nachází, se pozná z tzv. masky podsítě („subnet
mask“). To je bitové pole, kde jedničky označují místa, kde se nachází adresa sítě a kde nuly označují
adresu uzlu. Z důvodu jednoduchosti se používají masky spojité (jedničky a nuly následují
bezproředně za sebou), takže se někdy lze setkat i se zjednodušeným zápisem masky podsítě jako
bitové pozice, kde se nachází pomyslná hranice (často používaným termínem je „délka prefixu sítě“).
Jelikož nejde o původní vlastnost IP protokolu, informace o charakteru připojené sítě se nachází pouze
na směrovačích a koncových uzlech, v paketech obíhajících po síti masku podsítě nenajdeme.
To ale nevadí, ba naopak. Pokud totiž maska není v paketu pevně stanovena, je možné
geograficky blízké sítě, které jsou od směrovače ve třetí síti dostatečně daleko a dosažitelné po
stejném spoji, sdružit (zagregovat) do jakési jedné „nadsítě“ a zjednodušit tak páteřní směrování*.
Více koncových sítí tak bude dosažitelných pod jedním směrovacím záznamem. Čím se bude paket
blížit do své cílové sítě, tím budou informace o cílové síti detailnější a tím bude síťová část adresy
(prefix) delší. Tam ale zase bude paket dál od páteře a směrovač nebude potřebovat tolik informací o
jiných vzdálených sítích – přenechá je páteřním zařízením a všechny pakety do cizích sítí pošle
implicitní cestou do páteře pryč. Maska sítě, na základě které směrovače rozhodují o další cestě
paketu, se tedy v průběhu cesty jednoho paketu mění. Agregace adres a cest je mechanismus, který
usnadňuje směrování paketů.
*Páteřní směrovače – směrovače, které nepoužívají pro směrování na neznámé adresy „výchozí“ cestu ke směrovači vyšší
úrovně, ale musí znát směr do všech používaných sítí Internetu, protože nad nimi žádný další směrovač vyšší úrovně není)
strana 16
Objevily se i některé obtíže. Dříve pevný počet možných podsítí daný třídami A, B a C začal
být rozsekáván mechanismem CIDR na menší a menší sítě a ty začaly být přidělovány sítím v různých
lokalitách po celém světě. Spolu s rozvojem jemných a oddělených sítí začaly narůstat záznamy ve
směrovacích tabulkách páteřních směrovačů Internetu. Čím oddělenější totiž jemné sítě jsou, tím roste
pravděpodobnost, že nebudou dosažitelné po stejných spojích a že nepůjdou zpětně zagregovat do
„nadsítě“. Ve směrovací tabulce tak musí být pro každou síť jeden zvláštní záznam s dlouhým
prefixem namísto jednoho společného pro všechny sítě. A protože výkon těchto směrovačů není
neomezený a jejich paměť rozhodně nestačí na pojmutí adres všech koncových uzlů a ani koncových
podsítí, měly by mít páteřní směrovače přehled pouze hrubý a měly by uchovávat směrovací
informace pouze pro velmi obecné (krátké) prefixy. Pokud by byla agregace stále obtížnější, nutně by
se začal omezovat výkon páteřního směrování a tedy i rychlosti přenosu dat.
CIDR a VLSM tak pomáhají tím, že uvolňují a spoří IP adresy a umožňují směrovat na třetí
vrstvě i ve velmi malých sítích. Nicméně i přes výhody agregace a beztřídního směrování, které
zmenšuje počet směrovacích záznamů, začaly jejich přičiněním (díky rozsekávání celistvých sítí na
vícero geograficky oddělených) růst tabulky páteřních směrovačů. CIDR tedy pomohl, ale není
řešením ideálním – co se získalo na jednom místě (kapacita adres) se muselo na jiném místě
(jednoduchost směrování) vzít.
Přes to všechno není v adresním prostoru IP mnoho volného místa a je potřeba spořit i jinak.
Další řešení nabídla technologie NAT/PAT (Network/Port Address Translation) – překlad adres,
využívající i čísla TCP portů v transportní vrstvě pro pseudo-rozšíření adresního rozsahu.
NAT/PAT umožňuje skrýt celou síť s mnoha uzly za jedinou veřejnou IP adresu – vnitřní uzly
jsou pak očíslovány speciálním rozsahem, který se neinzeruje směrovačům ve vnější síti. Pakety z a do
této sítě pak mají v Internetu jedinou IP adresu a rozlišení na konkrétní uzel v síti se provede na
překládací bráně podle dříve přidělené asociace čísla portu.
NAT/PAT ovšem také není řešením ideálním, protože:
- Kombinuje síťovou a transportní vrstvu (používá v asociacích čísla portů a adres) do jediné.
Z vývoje TCP/IP plyne, že právě rozdělení do dvou vrstev přineslo Internetu významné výhody
při směrování
- Ruší bezstavovost IP (je nutno udržovat tabulku asociací).
- Omezuje plnou koncovou (end-to-end) konektivitu uzlů. Jde o myšlenku, že každý uzel na
Internetu by měl být schopen plně komunikovat s uzlem jiným bez nutnosti specifické konfigurace
nebo různých pomůcek. Požadavky pro tuto plnou konektivitu v poslední době narůstají: různé
vzájemné peer-to-peer služby (dochází ke spojení mezi dvěma uzly, které jsou na stejné úrovni
v poskytování síťových služeb – nejde o servery), datová spojení přímo mezi mobilními
zařízeními, plně duplexní přenosy zvuku, a obrazu, herní konzole a podobně.
- Je nutno použít speciální aplikační brány pro služby, které jsou uvnitř sítě a jsou poskytovány ven.
- Servisní protokoly (ICMP) lze použít jen omezeně.
- Je to další prvek v síti, který je nutné pořídit, konfigurovat, udržovat, zabezpečovat a který by
nemusel být.
To jsou závažné důvody, proč je NAT považován za pouze dočasné východisko a proč jej řada
odborníků neuznává jako řešení, které je v souladu s koncepcí a ideály původního TCP/IP. Nicméně
v úspoře IP adres překlad adres pomohl.
Další prostor na úspory se našel na aplikační úrovni – například u nejčastěji používaného
aplikačního protokolu HTTP lze ve verzi 1.1 specifikovat v požadavku jmennou adresu serveru. Tím
lze použít jediný server a jedinou IP adresu na provoz mnoha různých webových serverů (webhosting)
u poskytovatelů hostingových služeb. Rozlišení serveru podle jména uvedeného v URL, se provede až
na aplikační úrovni - DNS všechna různá doménová jména překládá na jedinou IP adresu.
Všechna výše uvedená a i jiná vylepšení IPv4 nicméně dle mého názoru nejsou dlouhodobým
řešením, které by zajistilo dostatečný adresní prostor pro všechny zájemce o připojení při současném
zajištění všech služeb. Druhy a počty zařízení, které je možné a vhodné k IP síti připojit neustále
rostou a byla by škoda jejich potenciál nevyužít. Ani CIDR, ani NAT, ani jiná aplikační řešení však
dlouhodobě problém nedostatku adres neřeší, jen oddalují. Zmíněné doplňky mají své problémy, které
zabraňují využívat některé síťové služby, omezují použití uzlů a směšují funkce a vlastnosti různých
vrstev OSI modelu dohromady, což z hlediska návrhu jednotného prostředí a idey oddělení funkcí
vrstev není dobře. IP protokol nové generace by měl řešit všechny problémy od základů.
strana 17
1.3.2. Bezpečnost
Problematika bezpečnosti se při vývoji původních protokolů vůbec neuvažovala, nebyla
součástí zadání. Protokol byl navrhován tak, aby byl co možná nejvíce efektivní a flexibilní. Proto
přenosové cesty založené na tomto protokolu nejsou nikterak zabezpečeny. Bezpečnost se týká dvou
věcí:
- zda je ten, kdo je uveden jako zdroj (odesílatel), skutečným původcem paketu
- zda jsou data zabezpečena proti „odposlechu“ na přenášené lince (šifrována)
IPv4 ani jednu z otázek neřeší a na síťové vrstvě spoléhá na důvěru připojených subjektů a
provozovatelů přenosových spojů. Toto paradigma plně odpovídá čistě akademickému či vojenskému
Internetu, nedá se ovšem plně aplikovat na jeho současnou komerční podobu.
První bezpečnostní otázka není příliš závažná. Při používání dominujícího protokolu transportní
vrstvy (TCP), kde se navazuje spojení, není podvrhnutí IP adresy úplně snadnou věcí. Z důvodu
směrovacích pravidel musí být útočník na stejné IP podsíti a buď příchozí pakety odposlouchávat,
nebo agresivně vystupovat jako původní počítač, což nezůstane v síti nepovšimnuto a zdroj se dá
velmi rychle najít. Přesto by bylo dobré i v této oblasti větší jistotu mít.
Důvěrnost přenášených dat je závažnější problém. Odposlechnutí dat může mít i stejně závažné
následky jako falešná identita, ale provést se oproti ní dá mnohem snadněji. Přenosové spoje Internetu
jsou různého druhu, vlastnictví a existuje možnost monitorovat na nich provoz. Na cestě k cíli na
druhém konci světa projde paket po různých spojích a vždy se nelze na diskrétnost vlastníka
přenosového okruhu spolehnout. A snadný je i odposlech na některých (zejména sdílených) médiích
v sítích LAN (např. nepřepínaný Ethernet).
Pokud je potřeba zajistit, že si přenášená data nikdo jiný nepřečte, musí se o to v současné době
postarat vyšší vrstvy síťového modelu (např. SSL) nebo je potřeba k IP implementovat ještě různé
doplňky (např. IPSec), které bezpečný přenos zaručí. Ty ovšem nejsou každým zařízením
podporovány a jejich implementace do IPv4 prostředí nemusí být snadné a levné (stejně jako jiná
proprietární řešení). Toto všechno zabraňuje masovému rozšíření všeobecných bezpečnostních
mechanismů na síťové vrstvě přímo ke stávajícímu IPv4.
Šifrování je velmi náročná aplikace na systémové zdroje, zejména na procesorový čas. Počítače
a směrovače existující v době vzniku IP protokolu (70. léta) nedisponovaly (až na výjimky) takovým
výkonem, aby mohlo být šifrování součástí každého přenosu dat a velmi rozumně tuto službu
přesunuli tvůrci do vyšších aplikačních vrstev – nechť se zpomalí až ten program, který bude
bezpečnost opravdu potřebovat. Situace se však změnila (jak v oblasti výkonu CPU, tak i v pojetí
ochrany dat) a služba by mohla propadnout v pojetí OSI modelu na nižší úroveň, například až do
síťové vrstvy. Je jen třeba dát pozor, aby se touto snahou neomezila jedna z hlavních výhod IP –
jednotnost, jednoduchý návrh a implementace pouze těch nejdůležitějších služeb. Zbytečná režie a
komplikovanost by mohla odsoudit i dobře míněný návrh vylepšení IP k neúspěchu.
1.3.3. Multicast
Původní pojetí IP sítě uvažovalo jako primární druh přenosu tzv. unicast – vyslání a příjem dat
mezi dvěma uzly. Pokud je potřeba po síti přenášet stejná data z jednoho uzlu k více dalším najednou
(tzv. multicast), bylo potřeba distribuovat je jako soubor unicastů. To není příliš šetrné k přenosové
kapacitě, protože se tytéž pakety, jen s rozdílnou síťovou adresou příjemce přenáší po tomtéž spoji
tolikrát, kolik je adresátů.
Služby, které by takové přenosy dat mohly s výhodou využívat, vznikly s rozvojem internetu a
přenosových kapacit – jde zejména o multimediální (rozhlasové a televizní) vysílání a
videokonference. S rostoucím počtem posluchačů a diváků roste i nárok na přenosové pásmo u
zdrojového serveru, což omezuje širší využívání služby. Řešením je použití některé z multicastových
přenosových technologií, neboli postupu, který shodná data bude vysílat pouze jednou a k rozdělení
koncovým příjemcům dojde až co nejblíže u nich, takže větší část cesty spoří přenosové pásmo.
Multicastové mechanismy se v síti implementovaly až dodatečně jako doplňková služba, takže
nejsou rozšířené na všech přenosových zařízeních. Nelze je tedy použít všude v Internetu a spoléhat se
na jejich existenci stejně, jako na možnost unicastového přenosu (který je základní službou).
Pro vícebodové přenosy byla později vyhrazena část IP adres a navrženy protokoly linkové i
síťové vrstvy, které jsou schopny tento druh dat směrovat a rozdělovat koncovým uživatelům.
Příkladem implementace těchto technologií je virtuální síť MBone v rámci Internetu používaná pro
strana 18
videokonference. Na směrovačích, které mají podporu multicastu implementovánu (tzv. „mrouter“) se
vícebodovými přenosy pracuje (směruje, duplikuje apod.) podle požadavků na multicast, tj.stejná data
se přenáší jen jednou. Přes ostatní směrovače je nutno postavit virtuální cesty (tunely) do další části
MBone sítě.
Implementace IPv4 multicastových protokolů (u kterých je oproti unicastům komplikovanější
směrování) však nejsou ve směrovačích Internetu tak rozšířené, aby se daly multicastové přenosy
využívat běžně každým, kdo by takový přenos potřeboval. I když jde o relativně nejméně problémový
bod IPv4, protože poptávka uživatelů sítě po multicastech zatím není velká, mělo by se při návrhu
nového síťového protokolu (pokud už se bude vytvářet) pamatovat i na nativní podporu multicastu ve
standardní implementaci. Dnes často používané řešení „silou“ neboli pomocí rozšíření přenosové
kapacity k vysílajícímu uzlu totiž nepůjde aplikovat věčně a služby na multicastu postavené by se
nemohly dále rozvíjet.
1.3.4. Kvalita služby
S multimediálními aplikacemi v reálném čase souvisí i další stále více sledovaný parametr
přenosu - kvalita služby. Data těchto aplikací jsou totiž velmi citlivá na šířku přenosového pásma a
zpoždění – pokud některý z požadovaných parametrů není dodržen, není možné službu vůbec
realizovat. To je rozdíl oproti klasickým datovým přenosům, kde se nedokonalosti projeví jen v čase,
kdy bude úkol dokončen, ale neznemožní se jeho provedení. Dnešní negarantované přenosy fungují na
principu best-effort, neboli směrovač udělám „maximum, co je v jeho silách“.
Pokud totiž na přeplněné lince nezbude pásmo pro minimální výstup kodeku videopřenosu, z
jeho sledování nebude nic. Stejně tak pokud se budou pakety v síti náhodně zpožďovat, nepodaří se je
na cílovém uzlu složit tak, aby byly v krátkém čase srozumitelně poslouchatelné, natož použitelné pro
obousměrnou konverzaci. A naopak - u FTP přenosu nebude příliš vadit kolísající rychlost podle
ostatního provozu na síti a prostoje, protože nejde o aplikaci v reálném čase a uživatel je schopen na
její výsledek počkat.
Jak zajistit pro určitá data prioritní zpracování a vyhrazené pásmo – jak garantovat kvalitu
přenosové služby? Původní IP protokol (až na několik zatím nepoužívaných bitů v hlavičce) žádné
standardní mechanismy nenabízí a je třeba v síti implementovat dodatečné technologie (např. nějakou
variantu WFQ – Weighted Fair Queueing na směrovačích podle určitých částí IP paketu). Lze také
preferovat data na směrovači jejich zařazováním do front s rozdílnou prioritou. Pokud ovšem nebudou
používány na celé přenosové trase od zdroje k příjemci, uplatní se jen částečně a zbytek cesty bude
opět s negarantovanými parametry.
Objevila se i řešení využívající garantované parametry na linkové vrstvě OSI modelu (např.
ATM má velmi dobrou podporu kvality služby), takže pak IP funguje v jakémsi virtuálním kanálu se
stálými parametry, ale jejich řízení není tak pružné jako směrování na síťové vrstvě a opět chybí
mechanismus vyhradit takto parametry po celé trase po různých spojích.
Nejjednodušší je opět řešení hrubou silou – zvýšit přenosovou kapacitu všech spojů a směrovací
výkon zařízení tak, aby úzká místa vůbec nevznikala. Datový provoz je ale schopen v krátkém čase
zaplnit jakékoliv kapacity a citlivá data by opět mohla narazit. Řešení spatřuji ve skutečné nativní
implementaci mechanismu prioritizace dat na všech směrovačích v síti. Pokud nebudou moci být
parametry zajištěny, aplikace se to dozví a zdroj nedostane.
I pro IPv4 prostředí byly navrženy nové protokoly RTP (Real-Time Transport Protokol) a
RSVP (Resource Reservation Protokol). Tyto standardy dokáží rychleji a plynuleji přenášet data a lépe
spolupracují se směrovači při rezervaci pásma pro přenos potřebného. Problémem je opět nízké
rozšíření implementací a malý počet aplikací, které jej využívají.
Požadavky na kvalitu služby se ze strany uživatelů ozývají stále častěji a jsou jedním z velkých
nedostatků IPv4. Spolu s rozsahem adres zřejmě půjde o nejvýznamnější motivy, které uspíší zavedení
nových přenosových technologií.
1.3.5. Mobilní zařízení, adresy a mobilita uzlu mezi sítěmi
Velkým fenoménem poslední doby je (vedle Internetu) bezesporu užívání mobilních zařízení.
Od jednoduchých GSM telefonů přes různé inteligentní organizéry, PDA až po notebooky - všechny
tyto přístroje jsou pro svou přenosnost a dostupnost jsou stále více užívány. A většinu těchto (a i třeba
ještě neznámých zařízení) by bylo možné a účelné připojit do nějaké celosvětové sítě, aby mezi sebou
strana 19
mohly vyměňovat data efektivním způsobem. Nabízí se samozřejmě Internet jako síť s velkým
objemem využitelného obsahu a službami, které by bylo škoda nevyužít (ať již z pohledu uživatele,
tak poskytovatele mobilního připojení). Internet by tak mohl být doslova „všude“, což je bezesporu
velkým lákadlem jako pro využití v práci, tak pro zábavu.
Při rozvíjení myšlenky mobilních datových sítí a jejich konvergenci s pevnými sítěmi byly
zjištěny dva základní nedostatky IP protokolu pro tento účel:
- nedostatek adres pro obrovské množství nových zařízení
- slabá podpora konceptu mobility neboli přesunu jednoho uzlu mezi sítěmi během přenosu bez
ztráty spojení
O nedostatku adres obecně bylo pojednáno výše, zde se problém jen zdůrazňuje a eskaluje.
Například podle prognóz firmy Nokia v roce 2003 překročí počet uživatelů mobilních sítí počet uzlů
v pevném Internetu – a tak velké úspory IPv4 adres se nedají očekávat.
Druhý problém je také důležitý – uzel v síti by se měl dát nalézt na své stálé adrese, i když je
dočasně v úplně jiné síti. Měl by mít možnost přesunovat se mezi různými sítěmi a zároveň stále
přenášet data bez přerušování a nové konfigurace.
Dřívější rozměry a hmotnosti dostupné výpočetní techniky na masovou mobilitu nedávaly ani
pomyslet. V IPv4 je to proto problém - původní koncept počítal s pevnými uzly a pevnými uživateli
(kteří pro svou případnou mobilitu využijí nějakého cizího nepřenosného uzlu a přihlášení do své
vlastní sítě vyřeší aplikačně). Mobilita vyžaduje úpravy na všech uzlech, které s ní mají co do činění,
jinak dochází k nežádoucím efektům (trojúhelníkové směrování a podobně). V IPv4, kde je pouze
volitelná a nemá podporu v řídících protokolech, ji nelze masově nasadit.
V mobilních sítích druhé generace s paketovým přenosem – GPRS jde v zásadě o implementaci
nějakého síťového protokolu (nejlépe IP) nad GSM. Ze strany výrobců mobilních zařízení existuje
velký tlak na implementaci nového IP protokolu pro nasazování do bezdrátových sítí, protože použití
IPv4 není z hlediska jejich předpokládaného rozvoje příliš vhodné. Jak adresy, tak mobilní přenosy by
bylo nutno řešit komplikovaně až doplňkovými službami, což by nebylo dobrou vizitkou nově vzniklé
služby (která by měla začít s co nejlepším návrhem standardů).
V mobilních sítích se brzy začne rozvíjet i třetí generace bezdrátových přenosů (UMTS) s větší
kapacitou přenosového pásma a větším potenciálem služeb pro uživatele. Vhodné řešení celého
problému by mohl přinést IP protokol nové generace, jehož adresový prostor by měl být dostatečný i
pro mobilní sítě fungující na paketovém principu přenosu dat (což je i GPRS). Z mobilních sítí by
mohl být na implementaci nového IP velký tlak – jde o oblast, která je potenciálně komerčně velmi
dobře využitelná, nicméně pouze za předpokladu zásadních novinek ve stávajícím síťovém protokolu a
infrastruktuře.
strana 20
2. Vlastnosti IPv6
2.1.
O této kapitole
Kapitola tvoří teoretický technologický základ diplomové práce, na kterém budu stavět při
svých pokusech v praktické části. Jde o popis dnešního stavu protokolů, specifikací, standardů a
navazujících služeb, které jsou přímo nazývány IPv6 nebo se přímo vztahují k IPv6. Text se zaměřuje
na novinky a změny v protokolu, záležitosti fungující stejně jako v IPv4 jsou jen obecně shrnuty
(předpokládá se čtenářova základní znalost principů fungování IPv4 protokolu). Tam, kde je to
vhodné, jsou porovnány schopnosti staré a nové verze.
Jako zdroje a prameny jsem (mimo RFC dokumentů) použil také [1,6,21,23].
2.2.
Specifikace a základní hlavička protokolu
IP verze 6 je nová verze protokolu síťové vrstvy Internetu – Internet Protocol. Bezprostředně
navazuje na předchozí verzi IPv4 definovanou standardem RFC 791. Jeho základní definici, včetně
popisu hlaviček protokolu (jádrové i rozšiřujících), obsahuje standard RFC 2460 [9].
Hlavním rozdílem oproti minulé verzi je rozšířená délka IP adresy na 128 bitů oproti původním
32 bitům. Podle návrhu tvůrců by již nikdy neměl nastat nedostatek adres a měl by se vytvořit
dostatečný prostor pro vytvoření bohaté hierarchie sítí a podsítí.
Zásadní změny jsou v hlavičce IP paketu. Některé položky z verze 4 byly vypuštěny a jiné
přesunuty do nepovinných hlaviček, takže prodloužení dat hlavičky je jen dvojnásobné (i přes
čtyřnásobný růst délky adres). Základní hlavička, kterou musí mít každý IPv6 paket, má na rozdíl od
IPv4 pevnou délku a mohou za ní být další rozšiřující informace v doplňujících hlavičkách (viz dále).
Pokud jsou přítomny, jsou v paketu uvedeny v pořadí důležitosti pro mezilehlé uzly – dříve uvedené
hlavičky mohou mít význam i pro směrování a měl by je zpracovat každý směrovač, nejen koncový
uzel (který musí interpretovat všechny hlavičky). Jejich uvedením vpředu tvůrci zamýšleli usnadnit
zpracování na směrovačích - stačí přečíst začátek paketu až do první hlavičky určené jen pro koncový
uzel. Směrovač zároveň nesmí při zpracování paketu hlavičky přeskakovat a vybírat si z něj jen
některé druhy hlaviček bez řádného zpracování těch předchozích.
Zvýšením délky hlavičky se protokol IPv6 lehce znevýhodnil při přenosu malých paketů (např.
aplikace přenášející zvuk v reálném čase používají pakety o velikosti desítek bajtů), protože vzrostl
podíl režijních informací. Nicméně by to neměl být závažný problém, protože při velkých paketech
není režie velká a problém nárůstu zpoždění u malých paketů z důvodu velkých hlaviček lze řešit
například jejich kompresí.
Základní hlavička obsahuje 40 bajtů dat a vypadá takto (každý řádek představuje 4 bajty):
0
8
Verze
Třída provozu
Délka dat
16
24
32
Značka toku dat
Další hlavička
Limit skoků
Zdrojová adresa
Cílová adresa
Obrázek 3: Základní hlavička IPv6 paketu
strana 21
Jaký je význam jednotlivých položek?
Verze protokolu (4 bity) bude v této specifikaci vždy rovna šesti.
Třída provozu (8 bitů) slouží pro označení příslušnosti paketu k určité třídě nebo prioritě služby.
Jde o analogii k položce „třída služby“ z IPv4 a je zde především pro podporu možných aplikací,
které jsou nyní zkoušeny v IPv4 (IP precedence apod.). Do budoucna se počítá s podrobnějším
vymezením významu těchto bitů. Celkově jde o koncept značkování jednotlivých paketů.
- Značka toku dat (20 bitů) může být použita vysílajícím uzlem k označování paketů stejného
datového toku (paketů s sebou úzce souvisejících), které vyžadují stejné zacházení od směrovačů
(zajištění kvality služby apod.). Toto pole lze využít také pro spolupráci s nižšími vrstvami (ATM,
MPLS apod.), které také značkování toků používají. Společné značky IPv6 a spojových
technologií mohou usnadnit zpracování dat na zařízeních a zkrátit nutné doplňkové informace.
Pojetí značky toku je dvojí – v průběhu cesty konstantní značka (pro účely podpory služeb se
zaručenou kvalitou a rezervaci pásma pro datový tok) a při průchodu uzly měnící se značka (např.
v MPLS). Podrobnější význam bude poli přidělen později, celkově jde o koncept značkování
celých toků.
- Délka dat (16 bitů) udává délku paketu bez základní hlavičky (ale včetně rozšiřujících). Je možno
přenášet i pakety větší délky než 2^16, tj. 64 kilobajtů pomocí doplňujících hlaviček (tzv.
jumbogramy).
- Další hlavička (8 bitů) udává typ bezprostředně následující hlavičky podle RFC 1700 (platného už
pro IPv4, nově též na www.iana.org) nebo identifikaci poslední hlavičky IP (začátku hlavičky
transportní vrstvy).
- Limit počtu přeskoků (8 bitů) má stejný význam jako „Time To Live“ – TTL hodnota v IPv4.
Každý směrovač musí při zpracování paketu snížit tuto hodnotu o jedničku. Pokud dojde k nule,
musí paket zrušit a vyslat kontrolní zprávu odesílateli o zrušení. Jde o ochranu proti nekonečnému
putování paketů v síti a používá se i při diagnostice v síti (mj. v nástroji traceroute).
- Zdrojová adresa (128 bitů) a Cílová adresa (128 bitů) mají stejný základní princip pro označování
uzlu a směrování, jako jejich kratší protějšky z IPv4. Podrobná specifikace významu jednotlivých
bitů je samozřejmě jiná (viz dále).
Paket neobsahuje rozdílně oproti IPv4 kontrolní součet, důvodem je opět zrychlení zpracování
paketů směrovačem – při kontrole integrity dat se nyní spoléhá na nižší vrstvy.
-
2.3.
Doplňující hlavičky
Vedle základní hlavičky je v IPv6 specifikováno ještě několik nepovinných, doplňkových
hlaviček. Ty se nacházejí mezi základní hlavičkou a datovým obsahem paketu (nejčastěji TCP
hlavičkou). Všechny doplňující hlavičky obsahují na začátku osmibitovou informaci o případné další
hlavičce (podle zmíněného RFC 1700) a délku hlavičky současné. Další obsah doplňkové hlavičky
závisí na jejím druhu.
Existují následující druhy rozšiřujících hlavičeky (uvedeny v pořadí, ve kterém by se měly
v paketu objevit, pokud je jich třeba):
- Základní IPv6 hlavička (viz výše)
- Parametry pro všechny mezilehlé uzly (tzv. Hop-by-Hop options),
- Parametry pouze pro koncový uzel (Destination Options) jsou oboje různé doplňkové informace
pro zařízení třetí vrstvy. Jejich struktura je tříprvková a označována anglickou zkratkou TLV –
type, length & value (typ, délka a hodnota). Typ je osmibitové pole udávající druh parametru,
délka je osmibitová položka udávající délku posledního pole – hodnotu (vlastního obsahu). První
dva bity v poli typ určují operaci, která se s hlavičkou provede, pokud směrovač ve své
implementaci neumí parametr nijak interpretovat.
- Směrovací hlavička (Routing header) obsahuje doplňkové informace pro směrování paketu. Jde
zejména o druh směrování, seznam adres uzlů, kterými by měl paket při své cestě projít a ukazatel
na ještě nenavštívené uzly. Její význam je zejména při podpoře směrování podle adresy
vysílajícího uzlu (source routing).
- Fragmentovací hlavička je používána zdrojovým uzlem pro rozdělení paketu, pokud je potřeba
přenést data větší, než je maximální přenosová velikost (Maximum Transmission Unit - MTU) na
linkové vrstvě pod IPv6 protokolem. Na rozdíl od IPv4 neprovádí fragmentaci paketu uzly po
cestě, ale jen a pouze první uzel. Musí tedy předem po celé cestě zjistit minimální MTU (MTU
strana 22
-
path discovery, [13]), aby bylo jisté, že pakety bude možno přenést po všech spojích. Hlavička
obsahuje zejména 32-bitovou identifikaci původního neděleného paketu, pořadí fragmentu a
označení toho, zda jde o poslední paket.
Autentizační hlavička obsahuje kontrolní informace pro ověření toho, zda nedošlo k poruše
integrity hlavičky. Jde zejména o číslo bezpečnostní asociace a kontrolní integritní hodnotu.
Podrobněji viz podkapitola o podpoře bezpečnosti.
Šifrovací hlavička (Encapsulating Security Payload Header) udává začátek šifrovaného proudu dat
a různé konfigurační údaje nutné pro jeho pozdější dešifrování. Podrobněji viz podkapitola o
podpoře bezpečnosti.
Hlavička dat transportní vrstvy (např. TCPv6) již není záležitostí IP. Pokud je v poli určující další
hlavičku hodnota 59 dekadicky, jde o poslední hlavičku IP protokolu.
Příklad tří různých druhů řazení hlaviček v paketu je uveden na obrázku:
Základní hlavička
další: TCP
Hlavička TCP segmentu
+TCP data…
další: směrovací
Směrovací hlavička
další: TCP
Hlavička TCP segmentu
+TCP data…
další: směrovací
Směrovací hlavička
další fragmentovací
Fragmentovací hlv.
další: TCP
Fragment TCP hlavičky
+TCP data…
Obrázek 4: Doplňující hlavičky IPv6 paketu
2.4.
Velikost paketu
Popis nového protokolu specifikuje také určitá omezení, které je třeba brát v úvahu při
sestavování velikosti dat a fragmentování i mimo síťovou vrstvu. IPv6 totiž požaduje, aby byl každý
spoj na přenosové cestě schopen přenést paket o velikosti alespoň 1280 bajtů (tj. aby MTU bylo
alespoň takové nebo větší).
Na spoji, který to není schopen provést, musí být provedena fragmentace na nižší úrovni,
nikoliv pomocí IPv6. Spoje, kde je možno maximální velikost přenosové jednotky volit, musí být
nastaveno alespoň 1280 bajtů, lépe však 1500 bajtů a více (aby bylo nutno fragmentovat na IP vrstvě
co nejméně). U IPv4 je velikost paketu omezena pouze MTU linkové vrstvy.
Velmi se doporučuje, aby uzly sítě implementovaly protokol „Path MTU Discovery“ (viz
kapitola o servisních protokolech) neboli zjišťování velikosti MTU na všech spojích zamýšlené cesty
paketu, aby uzly mohly využít výhod většího povoleného paketu. U minimálních implementací
(například v ROM síťové karty) nemusí být vyhledávání MTU prováděno a pakety musí mít vždy
1280 bajtů.
K poslání paketu většího, než je nejmenší MTU na zamýšlené cestě, je možné na zdrojovém
uzlu použít IP fragmentaci (pomocí doplňkových hlaviček) a cílový uzel si potom paket sestaví.
Každý koncový uzel v IPv6 musí být schopen přijmout fragment, který bude po sestavení veliký 1500
bajtů (nicméně může být schopen přijmout i větší). Aplikace nebo vyšší vrstva, která na IPv6 závisí,
by neměla posílat pakety větší než 1500 bajtů, pokud si není jista, že koncový uzel je schopen takové
pakety sestavit.
Pokud je paket odeslán z uzlu podporujícího IPv6 na uzel s IPv4 (tzn. při cestě dojde k překladu
paketu), vysílající uzel může obdržet řídící zprávu, že MTU následujícího spoje je menší než 1280
(ICMP Packet Too Big). V takovém případě není třeba snižovat u odesílaných paketů velikost pod
1280 bajtů, ale k paketu se musí připojit fragmentační hlavička, ze které překládající uzel bude
schopen získat identifikační klíč, který pak použije v IPv4 fragmentech.
strana 23
2.5.
Adresování v IPv6
2.5.1. Základní principy
Hlavní změnou je bezesporu čtyřnásobné zvětšení velikosti adres na 128 bitů. Větší délka
nebyla využita pouze mechanicky („nalepena“) ke stávajícím 32 bitům, ale byl stanoven nový význam
jejích částí a druhů. Adresy jsou stejně jako v IPv4 přiřazovány jednotlivým síťovým rozhraním
(network interface) uzlů, nikoliv uzlům jako celku.
Existují tři základní druhy IPv6 adres:
- Unicast (jednotlivé) – významem odpovídají původním individuálním IP adresám. Jedna takováto
adresa bude přiřazena jednomu síťovému rozhraní.
- Multicast (skupinové) – významem odpovídají adresám používaným pro multicast (posílání
stejných dat od jednoho zdroje více příjemcům). Jedna takováto adresa může být přiřazena více
síťovým rozhraním a pakety by měly být dopraveny na všechna z nich.
- Anycast (výběrově-skupinové) nemají přímý ekvivalent v IPv4. Jedna takováto adresa může být
přiřazena více síťovým rozhraním, ale paket bude dopraven pouze na jedno z nich.
Jaké mají tyto druhy adres použití? U unicastu je zřejmé, jde o základní použití pro přenos dat
mezi dvěma uzly (většina přenosů v Internetu), směrování ukazuje cestu vždy jednoznačně do cílové
sítě a paket není po cestě duplikován.
Multicast se používá pro hromadné vysílání stejných dat více uzlům (například televizní a
rozhlasové vysílání, videokonference apod.), paket je směrován a rozesílán více zařízením, která se
ohlásí zvolenou skupinovou adresou.
Anycast lze použít pro konfigurační dotazy, rozkládání zátěže serverů a podobně – všude tam,
kde stačí, aby paket nalezl jen jedno zařízení, které mu je schopno poskytnout danou službu. Další již
nejsou potřeba a směrování bude ukazovat cestu pouze k nejbližšímu (dle vzdálenostní metriky
směrovacího protokolu) připojenému uzlu s danou výběrově-skupinovou adresou. Ostatní uzly budou
ignorovány až do změny topologie sítě, výpadku uzlu a podobně, kde se sestaví cesta k nejbližšímu
dalšímu. Využití anycastových adres se nabízí například u vyrovnávání zátěže („load-balancing“, LB)
webových nebo DNS serverů, v sítích, kde je třeba zajistit redundancí vysokou dostupnost („highavailability“, HA) služeb, volba nejbližší výchozí cesty ze sítě a podobně. Mechanismus samozřejmě
neřeší LB ani HA na aplikační úrovni (sledování aktuálního zatížení, přesun existujících
rozpracovaných dat apod.), nicméně velmi pomáhá vytvořit základní kostru, na které je tyto služby
možné implementovat.
V IPv6 již neexistují tzv. broadcast (všesměrové) adresy, směrující pakety na všechny uzly
v dané síti, používané zejména ke konfiguračním účelům a posílání řídících zpráv. Místo nich je
možné používat skupinové nebo výběrově-skupinové adresy, které specifikují cíl přesněji.
Individuální adresy se dále dělí podle rozsahu na tři druhy:
- Global (globální rozsah) – jsou jednoznačné v celém internetu.
- Site local (oblastně místní rozsah) – jsou jednoznačné v rámci jedné instituce nebo její zvolené
podčásti.
- Link local (spojově místní rozsah) – jsou jednoznačné v pouze rámci dané fyzické sítě.
Globální adresy mají stejný charakter jako dnešní veřejné IP adresy. Místní adresy pak
připomínají z hlediska směrování dnešní privátní adresy (192.168.X.X), které se do veřejného
Internetu neinzerují. Jsou jednoznačné jen v rámci zvolené oblasti a mohou být tedy ve světě použity
vícekrát.
Každé rozhraní, které je připojené k IPv6 síti, musí mít přiřazenu alespoň jednu spojově místní
unicastovou adresu. Rozhraní pak může mít přiděleno větší počet dalších adres různých druhů a
rozsahů. Jednomu spoji je možno přiřadit více prefixů podsítí. Pokud není daný interface používán
nesousedními uzly jako zdroj nebo cíl pro cizí IP pakety (např. na dvoubodových spojích mezi
směrovači), není třeba rozhraní přidělit další adresy vyššího rozsahu než spojově místního.
Unicastová adresa může být přiřazená více fyzickým rozhraním, pokud obslužná aplikace
považuje všechna fyzická rozhraní za jedno logické rozhraní ve vztahu k síťové vrstvě. V případě, že
koncové uzly se stejnou adresou rozhraní jsou nakonfigurovány jako výběrově skupinové (anycast),
stane se z oné unicastové adresy anycastová. Podle prefixu jsou totiž anycastové adresy nerozlišitelné
od unicastových, liší se až jejich zpracování směrovačem a konfigurací na koncových uzlech.
strana 24
Při použití anycastu je třeba určit síťový prefix (oblast), kde se všechna rozhraní příslušející
k dané anycastové adrese nacházejí a kde se tedy bude směrovat anycastově. V této oblasti bude cesta
ke každému jednotlivému uzlu určená jako tzv. host route (s délkou prefixu 128 bitů). Mimo tuto
oblast bude možné směrovací cesty běžným způsobem agregovat.
S anycastem v globálním měřítku jsou zatím malé zkušenosti a širší použití může přinést jistá
rizika. Plánované využití je například pro označení skupiny směrovačů starajících se o provoz ven
z menší organizace (nebo ISP) a podobně. Použití anycastu v oblasti s nulovým prefixem (v celém
Internetu) bude velmi omezené z důvodu obav o zatížení směrovacích tabulek velkým množstvím
neagregovatelných cest. Prozatím není dovoleno uvádět anycastové adresy jako zdrojové v IP
paketech a není dovoleno je přiřadit jiným uzlům než směrovačům.
Specifický typ a záběr IP adresy je možné poznat pomocí úvodních bitů celé adresy, které jsou
uvedeny v tabulce (zdroj: [17]). Je zřejmý velký podíl (85 %) adres s dosud nepřiřazeným významem,
tučně jsou vyznačeny adresy, se kterými je možné se dnes setkat nejčastěji.
Přiřazený účel
Bitová kombinace
Rezervováno (+ několik výjimek)
Nepřiřazeno
Rezervováno pro NSAP
Rezervováno pro IPX (zřejmě se změní)
Nepřiřazeno
Nepřiřazeno
Nepřiřazeno
Globální unicastové adresy
Nepřiřazeno
Nepřiřazeno
Nepřiřazeno
Nepřiřazeno
Nepřiřazeno
Nepřiřazeno
Nepřiřazeno
Nepřiřazeno
Nepřiřazeno
Nepřiřazeno
Spojově místní unicastové adresy
Oblastně místní unicastové adresy
Multicastové adresy
0000
0000
0000
0000
0000
0000
0001
001
010
011
100
101
110
1110
1111
1111
1111
1111
1111
1111
1111
0000
0001
001
010
011
1
0
10
110
1110 0
1110 10
1110 11
1111
Hexadecimálně
00
01
02-03
04-05
06-07
08-0F
1
2-3
4-5
6-7
8-9
A-B
C-D
E
F0-F7
F8-FB
FC-FD
FE0-FE7
FE8-FEB
FEC-FEF
FF
Unicastové adresy jsou agregovatelné stejným způsobem, jako IPv4 adresy pomocí mechanismu
CIDR. Uzel v síti podle svého významu může adresu považovat za jednolitou (koncový uzel), dělenou
na několik málo částí (přístupový směrovač) a detailně členěnou (páteřní směrovač). Agregace pak
spočívá v možnosti sdružovat adresní záznamy jen podle některých částí (nejčastěji podle prefixů sítí
ve směrovacích tabulkách).
Adresa uzlu v dané síti (část za prefixem) může být podobně jako v IPv4 nezávislá na nižších
vrstvách a koncové uzly v podsíti je možné číslovat například sekvenčně podle pořadí připojení od
jedničky výše. Šířka adresy v IPv6 nabízí ovšem i jiné možnosti přidělování adresy rozhraní za
prefixem, například využitím 64-bitového identifikátoru rozhraní IEEE EUI-64. Ten lze automaticky
sestavit z MAC adresy linkové vrstvy (např. čísla Ethernetové karty) rozhraní a dalších uzlu
dostupných informací. Použití unikátního EUI-64 může usnadnit automatickou konfiguraci a přidělení
celé IP adresy, protože nebude nutno zjišťovat, která uzlová adresa už byla přidělena jinému uzlu.
V prvním rezervovaném rozsahu existuje několik výjimek. Jednou z nich je adresa obsahující
samé nulové bity, která se nazývá nespecifikovaná a neměla by být přiřazena žádnému uzlu. Jako
zdrojová adresa v paketu označuje síťové rozhraní, které zatím nemá přidělenu IP adresu (například
při automatické konfiguraci).
Další výjimkou je tzv. loopback, adresa zpětného rozhraní, která by neměla být přiřazena
žádnému fyzickému rozhraní a nesmí ji jít směrovat. Zpětná adresa je až na poslední jedničkový bit
také nulová a slouží uzlu k poslání paketů sobě.
strana 25
Obě tyto speciální adresy mají ekvivalent v IPv4 jako 0.0.0.0 a 127.0.0.1.
Pro směrování v duálním protokolovém prostředí (IPv4/IPv6), kterému se Internet při přechodu
na novou verzi nevyhne, byly dále vyčleněny adresy, které umožní zapsat IPv4 adresu pro použití v
IPv6 paketu. Měly by umožnit dynamicky směrovat IPv6 pakety přes IPv4 infrastrukturu a usnadnit
komunikovat klientům, kteří mají implementován jiný protokol. Taková adresa má prvních 80 bitů
nulových a posledních 32 bitů odpovídá IPv4 adrese. Zbývajících 16 bitů je buď nulových (pokud
daný uzel podporuje i IPv6) nebo jedničkových (pokud podporuje pouze IPv4). Příklad takových adres
je uveden v další podkapitole.
2.5.2. Zápis adres a prefixů sítí
Jakým způsobem se adresy zapisují v textové formě? Použití dekadického zápisu čtyř čísel
oddělených tečkami známého z IPv4 by vzhledem k nárůstu délky nebylo praktické. Tvůrci zvolili v
[17] reprezentaci v šestnáctkové soustavě, kde se dvojice bajtů (čtveřice hexadecimálních číslic)
adresy oddělují dvojtečkou. Vznikne tedy osm polí oddělených dvojtečkami.
2001:FE0C:01D3:0000:0000:0000:0FF9:D5BA
Obrázek 5: Příklad zápisu základní formy IPv6 adresy
Vzhledem k charakteru přidělování IP adres a jejich nejčastějších hodnot lze zápis různými
způsoby zkracovat. Počáteční nuly v každé čtveřici se nemusí uvádět. Pokud je dvojice bajtů mezi
dvojtečkami celá nulová, lze čtyři nuly nahradit jedinou. Delší pole nulových bajtů je možné nahradit
dvojicí dvojteček „::“. Ty se mohou v adrese objevit na začátku, na konci i uprostřed, ale v jednom
zápisu pro zajištění jednoznačnosti vždy jen jednou.
2001:FE0C:1D3::FF9:D5BA
Obrázek 6: Příklad zápisu zkrácené formy adresy
V období současné existence protokolů verze 4 a 6 je vhodné zapisovat adresy tak, jak jsou
uživatelé a správci zvyklí z obou systémů současně. IPv4 adresa se uvede v nejnižších 4 bajtech IPv6
adresy a zapíše se dekadicky, zbylých horních 12 bajtů se popíše hexadecimálně. Zápis adresy tak
bude mít deset polí oddělených dvojtečkami a tečkami.
2001:FE0C:1D3::15.249.213.186
Obrázek 7: Příklad kombinovaného zápisu IPv4 v IPv6 adrese
Zápis není jednoduchý a už ne snadno zapamatovatelný. Zdá se, že použití jmenných služeb
překládající číselné adresy na jména a naopak bude na rozdíl od IPv4 nezbytné i pro správce. Nicméně
podle RFC 2732 [14], které rozšiřuje definici URL o zápis IPv6 adresy v hranatých závorkách, bude
možné zadávat adresu číselně i přímo v URL (a tedy i v adresním řádku internetového prohlížeče).
http://[2001:FE0C:1D3::FF9:D5BA]:80/index.html
Obrázek 8: Příklad číselného zápisu adresy v URL
Síť nebo podsíť se popíše podle vzoru „prefix_sít•/délka_v_bitech“, kde „prefix_sít•“ je
IPv6 adresa v některém z povolených tvarů uvedených výše. Při zápisu adresy celé sítě se v místech
adresy uzlu uvedou nuly. Bitová délka se pohybuje teoreticky v intervalu 0-128 a stejně jako v IPv4
označuje místo (pomyslnou hranici) v adrese, kde končí označení sítě a začíná označení koncového
uzlu. Pokud chceme specifikovat jak délku prefixu, tak i adresu koncového uzlu, lze použít
kombinovaný zápis v jednom všech informací v jednom řádku.
2001:FE0C:1D3::/64
2001:FE0C:1D3::FF9:D5BA/64
Obrázek 9: Příklad zápisu sítě a uzlu v této síti
strana 26
2.5.3. Členění adresy
Adresu lze rozčlenit do částí, které mají různý význam. Ten závisí na dosahu (scope) adresy,
který zahrnuje. Bitům z adresy byl přiřazen význam podle předpokládané hierarchie poskytovatelů
internetového připojení od páteřních po koncové tak, aby přidělování adres této struktuře co nejvíce
odpovídalo. Důvodem tohoto dělení adresního schématu je snaha o efektivní agregaci směrovacích
záznamů jak podle poskytovatelů, tak podle propojovacích bodů sítí (exchange points, např.
v Čechách NIX). Obecně je snaha pro směrovače bez implicitní cesty minimalizovat objem
směrovacích cest v jejich tabulkách.
Globální adresa má v současnosti následující tříúrovňové schéma (dříve byl význam jiný, [18]):
03
I TLA
16
48
NLA
64
SLA
128
ID rozhraní (EUI-64)
Obrázek 10: Členění globální adresy
-
I je standardní identifikátor pro globální adresu (3 bity), je roven binárně 001 (viz tabulka výše).
TLA (top level aggregation, 13 bitů) je identifikátor agregační instituce nejvyšší úrovně (například
globálního a páteřního poskytovatele nebo propojovacího bodu).
- NLA (next level aggregation, 32 bitů) je identifikátor agregační instituce další úrovně v pořadí
(například přístupového nebo lokálního poskytovatele). NLA a TLA odpovídají topologii
„veřejného“ Internetu, neboli sítě mimo koncovou připojenou organizaci.
- SLA (site level aggregation, 16 bitů) je agregační identifikátor pro jednu lokalitu (například pro
jednu instituci). Rozdělení v poli SLA odpovídá topologii místní sítě.
- zbytek adresy tvoří 64 bitový identifikátor síťového rozhraní samotného koncového uzlu
(sestaveného například podle EUI-64).
Celá adresa je tedy sestavena z identifikátorů, jejichž přidělení si lze zjednodušeně představit
následujícím způsobem:
• Poskytovatel nejvyšší úrovně dostane od registrační autority přidělen identifikátor (prefix
sítě), v jehož rozsahu může přidělovat identifikátory nižší úrovně svým zákazníkům ISP, kteří jsou na něj napojeni. Originální prefix bude nejkratší.
• Tito ISP pak budou v rámci svého identifikátoru přidělovat číselné kombinace pro své
klienty. Jim přidělené prefixy budou delší než ty, které získali sami (budou přidělovat
pouze jejich části, ne celé).
• Klienti, koncoví zákazníci těchto ISP, si přidělený prefix (nejčastěji délky /48) rozdělí
podle své potřeby plochým nebo hierarchických způsobem do podsítí.
• Při směrování tak půjde záznamy ve směrovacích tabulkách snadno agregovat podle
prefixu celé instituce, přístupového ISP, propojovacího bodu nebo páteřního
poskytovatele internetové konektivity.
Konkrétní mechanismy přidělování globálních adres jsem podrobněji popsal v praktické části
diplomové práce.
Pro adresy spojově jedinečné není potřeba přidělovat prefix vůbec (nemusí se vůbec směrovat) a
používá se jen posledních 64 bitů identifikátoru rozhraní. U lokalitně místních adres (adres
jedinečných v rámci dané lokality - „site local“) je pro směrování potřeba jen 16-ti bitový prefix
podsítě (SLA část adresy) v dané organizaci.
Místní adresy jsou určeny pro adresování bez nutnosti mít přiděleny agregační identifikátor
(globální prefix) centrální autoritou. Směrovače ovšem nesmí inzerovat místní adresy mimo rozsah
jejich působnosti (spoje nebo lokality) a nesmí mimo rozsah posílat žádné pakety s takovou zdrojovou
nebo cílovou místní adresou.
2.5.4. Multicastové adresy
Skupinové (multicast) adresy jsou podle definice IPv6 dvou druhů – stálé a dočasné. Stálé jsou
přiřazeny oficiální autoritou a mají dosah po celém Internetu. Dočasné adresy mají dosah (lze je
směrovat) pouze v předem stanovené oblasti a nemají globální platnost. Součástí skupinové adresy je
strana 27
také bližší specifikace místa, kde se má multicast distribuovat – vedle spojově místního (link local) a
lokalitně místního (site local) rozsahu lze použít ještě rozsah pro daný uzel (node local) a danou
organizaci (organization local).
Adresy začínají osmi jedničkovými bity, v šestnáctkovém zápisu adresy FF (viz prefixy
uvedené v tabulce výše), což je identifikátor skupinových adres (M). Dalších osm bitů je používáno
pro definici dosahu platnosti (D) adresy a různé příznaky (P). Zbývajících 112 bitů slouží jako
identifikátor multicastové skupiny, které adresa patří. V současné době je přiřazován jako identifikátor
skupiny pouze nejnižších 32 bitů adresy, zbylé bity jsou rezervovány pro pozdější použití.
0
8 12 16
M PD
128
multicastová skupina (112 bitů)
Obrázek 11: Členění multicastové adresy
Existuje také několik skupinových adres, které mají předem stanovený význam a nesmí být
použity jinak. Obecně jde o analogii všesměrových (broadcast) adres z IPv4. Jde o adresy:
- všech uzlů (FF0X:0:0:0:0:0:0:1, na místě „X“ jsou různé hodnoty podle požadovaného dosahu),
- všech směrovačů (FF0X:0:0:0:0:0:0:2, opět různé hodnoty podle dosahu) a
- vyžádaných (solicited) uzlů což je kombinace prefixu FF02:0:0:0:0:1:FF/104 s nejnižšími 24 bity
unicastové nebo anycastové adresy uzlu. Slouží zejména pro agregaci a snížení počtu
multicastových skupin, ve kterých musí uzel být, pokud má rozhraní více unicast/anycast adres.
V RFC 2375 je uveden obsáhlejší seznam pevně specifikovaných adres v podrobnějším členění
(např. všechny směrovače RIP, všechny směrovače OSPF, všechny DHCP servery, všichni mobilní
agenti a podobně). Multicastové adresy se podle specifikace nikdy nesmí objevit jako zdrojové v IP
paketu.
2.6.
Automatická konfigurace a objevování okolí
Každý koncový uzel IPv6, který o sobě zjišťuje informace, musí být schopen ze svého okolí
získat následující adresní informace:
- spojově místní adresu,
- přiřazené unicast adresy,
- loopback adresu,
- skupinové adresy pro všechny ostatní uzly v dané síti,
- skupinové adresy pro unicast a anycast adresy, které jsou mu přiřazeny,
- skupinové adresy pro ostatní skupiny, jejichž je členem.
-
Směrovač musí být schopen zjistit stejné informace, jako koncový uzel, a navíc ještě:
anycastové adresy skupiny směrovačů, do které patří,
anycastové adresy všech ostatních skupin, do kterých patří,
skupinovou adresu pro všechny ostatní směrovače,
skupinovou adresu pro ostatní skupiny, do kterých náleží.
Přičemž v implementaci může být napevno stanoveno pouze:
nespecifikovaná adresa (0:0:0:0:0:0:0:0),
loopback adresa (0:0:0:0:0:0:0:1),
multicastový prefix (FF),
spojově místní a lokalitně místní prefixy,
standardizované skupinové adresy,
prefixy kompatibilní s IPv4.
Adresních informací není málo a spolu s dalšími nutnými údaji pro komunikaci (např. adresy
DNS serverů) je tedy potřeba uzly důkladně konfigurovat. Vzhledem k charakteru adres (špatně
zapamatovatelné, dlouhé na zápis) by manuální konfigurace, kdy správce zadá údaje každému uzlu
ručně, nebyla příliš praktická.
-
strana 28
Při návrhu nového protokolu se prosadila myšlenka „plug and play/zapojit a fungovat“ počítače
do sítě – neboli implementace protokolu by měla být schopna získat co nejvíce konfiguračních
informací sama [11]. To se vztahuje zejména na koncové uzly – směrovače je potřeba částečně
konfigurovat ručně (ale i směrovač může některé, například spojově místní adresy generovat sám).
Každý připojený uzel by měl být sám schopen „rozhlédnout se“ po síti (nejčastěji multicastem
na spojové vrstvě a dotazy pomocí ICMP protokolu na síťové vrstvě) a získat informace o okolních
připojených rozhraních – o jejich IP a MAC adresách, dosažitelnosti a podobně (RFC 2461 [10]).
Mechanismus je nazýván „Objevování sousedů/Neighbor Discovery“ [10] a je úzce spjat s protokolem
ICMP. Objevování je v praxi řešeno dotazy rozesílanými neorientovaným počítačem a odpověďmi
„poučenějších“ uzlů, kteří mu doplní chybějící údaje.
Specifickým případem okolního uzlu je pak směrovač, od kterého je možné dozvědět se mnoho
podrobností o síti, získat výstupní cestu z lokální sítě, prefix sítě, MTU a podobně. Existují standardní
skupinové adresy pro oslovení všech směrovačů v dané oblasti (tzv. Router Solicitation) a ty musí
vysílajícímu uzlu odpovědět. Směrovač také v periodických intervalech rozesílá aktualizaci síťových
informací sám (tzv. Router Advertisment). „Objevováním“ svých sousedů také uzel zjistí, zda
nepoužívá duplicitní síťovou adresu a že pro poslání odchozích paketů může použít jiný, výhodnější
směrovač.
Tento mechanismus v síti zcela nahrazuje protokol ARP a pozměňuje použití funkcí ICMP
Redirect a ICMP Router Discovery z IPv4 (protokol ICMPv6 pro IPv6 existuje v pozměněné formě –
viz další podkapitola).
Způsoby automatické konfigurace uzlu jsou dvě. V IPv4 existuje stavový (stateful)
mechanismus DHCP (Dynamic Host Control Protocol) a jeho upravená varianta existuje i pro verzi 6.
Jde o konfiguraci pomocí serveru v síti, který poskytuje předem známou cestou konfigurační
informace (adresy uzlů, prefix sítě, adresy DNS serverů, výchozí bránu a podobně). Novinkou je širší
spektrum poskytovaných údajů (časová zóna, adresy NTP serverů, parametry TCP protokolu apod.) a
možnost zaslání rekonfiguračního příkazu klientovi, který přikazuje uzlu vyžádat si některou
informaci od serveru znovu. Přístup lze použít v síti, kde jsou stanovena přesná pravidla přidělování
adres jednotlivým uzlům a správa je centralizovanější.
Druhou možností automatické konfigurace je tzv. bezstavová (stateless, RFC2462 [11]) – bez
nutnosti použít dedikovaný server. Nově zapojený síťový uzel získá informace o okolí objevováním
sousedů. Uzel sestaví svou adresu jako kombinaci prefixu sítě, který získá z informací směrovače (tu
směrovače periodicky rozesílají do sítě nebo si ji lze vyžádat), a identifikátoru svého síťového rozhraní
(např. podle EUI-64). Pro posílání žádosti o informace nekonfigurovaného uzlu se jako cílová adresa
použije některá ze standardních skupinových adres (viz výše) a jako zdrojová se uvede
nespecifikovaná adresa.
Po ověření jednoznačnosti adresy (v rámci daného rozsahu, s výjimkou anycastových adres) a
získání adresy výchozího směrovače, může uzel normálně fungovat, aniž by musel mít předem
nastaven jediný konfigurační údaj. Přístup se dá použít v sítích, kde není přesně určeno, který uzel
(která síťová karta) bude mít kterou IP adresu.
Přidělení adresy může být časově omezeno – v takovém případě je potřeba po vypršení limitu
získat konfiguračním mechanismem adresu jinou. Při změně IP adresy uzlu během jeho chodu dojde
k přechodové fázi, kdy zařízení dostane adresu novou, ale zároveň platí stále stará. Původní TCP
spojení dokončí svou činnost pod starou adresou, všechna nová budou již zakládána s adresou
aktuální. Problém změny adresy za chodu je ovšem komplikovanější (aplikace vyšší vrstvy může
tvrdošíjně stále používat starou adresu a není cesty, jak ji přinutit ke změně) a nebudu se mu
podrobněji věnovat.
Oba způsoby automatické konfigurace (stavová a bezstavová) se vzájemně nevylučují a mohou
se vhodně doplňovat. Uzel například sestaví adresní a základní směrovací informace bezstavově a
doplňkové údaje (například adresy základních síťových služeb, třeba DNS) zjistí z konfiguračního
serveru. Způsob, jaký mají uzly pro svou konfiguraci použít, se dozví z ohlášení směrovače.
2.7.
Směrovací protokoly
Pro směrování nového síťového protokolu jsou potřeba také nové, nebo alespoň upravené verze
směrovacích protokolů. Ty se dají členit podle rozsahu na dva druhy – interní (IGP) a externí (EGP).
První druh slouží pro směrování provozu v sítích v rámci jednoho autonomního systému (pod správou
strana 29
jedné autority), druhé pak pro výměnu mezi hranicemi autonomních systémů (tedy zejména
v páteřních sítích).
Interní směrovací protokoly se dále podle způsobu výpočtu směrovací tabulky dělí na distancevector a link-state algoritmy (více o směrovacích protokolech je uvedeno v [3]). Široce používaným
zástupcem první skupiny je protokol RIP (Routing Information Protocol), jehož historie sahá až do
počátků ARPANETu. Pro svou relativní jednoduchost je používán zejména v menších sítích.
Vzhledem k omezením směrování na 15 přeskoků a fixní používané metrice, která nebere v úvahu
aktuální parametry spoje (rychlost, zpoždění, zatížení apod.), ale jen počet přeskoků, se pro větší sítě
nehodí. Jeho princip spočívá v periodické výměně směrovacích tabulek (které obsahují záznamy ve
struktuře: prefix cílové sítě, celkový počet skoků a adresa dalšího skoku) mezi sousedními směrovači,
které o nově získané informace obohatí své stávající záznamy, a opět je avizují dále. Mechanismus
RIPu nemusel být oproti IPv4 speciálně měněn a proto RFC 2080 popisuje jen rozšíření
stávajícího RIPv2 o delší adresy na verzi RIPng.
Příkladem link-state směrovacích algoritmů je OSPF (Open Shortest Path First). Na rozdíl od
vzdálenostně-vektorových mechanismů nedochází k výměně směrovacích tabulek, ale jen informací o
stavu linek připojených ke směrovačům. Každý směrovač v oblasti, která pracuje algoritmem OSPF,
musí být schopen ze získaných informací o spojích sestavit plán celé sítě. Podle plánu sítě, kde jsou
všechny cesty ohodnoceny rozličnými metrikami podle jejich rychlosti, zpoždění apod., pak směrovač
vypočítá nejkratší cestu a paket tím směrem pošle. Svým založením je protokol vhodnější i pro větší
sítě, nicméně je složitější na implementaci.
Nový OSPF pro IPv6 je definován dokumentem RFC 2740 [15]. Fundamenty protokolu
(rozdělení sítí na oblasti, volba hlavního směrovače oblasti, výpočet ideální cesty, výměna informací
apod.) zůstaly od IPv4 stejné.
Změny nicméně jsou, nový protokol:
- Neobsahuje vlastní pole pro autentizaci, protože tu zajistí podpora přímo zabudovaná do IPv6.
- Nečlení prostor podle podsítí, ale podle jednotlivých spojů (protože v IPv6 může být na jednom
spoji více podsíti).
- Byl zobecněn tak, aby jádro protokolu bylo nezávislé na konkrétní podobě adresy (aby fungoval i
pro jiné směrované protokoly než IPv4 a IPv6).
- Byl upraven pro podporu spojově místních a lokalitě místních adres.
- Může existovat ve více nezávislých instancích směrovacího algoritmu najednou na jednom spoji.
- Obsahuje další drobná zlepšení jako přesunutí podpory typu služby (TOS) přímo do IP paketu,
konzistentní označování směrovačů v oblasti ID a podobně.
Z externích směrovacích protokolů se v IPv4 světě používá BGP (Border Gateway Protocol, dle
RFC 1771). Ten využívá spolehlivého TCP spojení pro výměnu informací o dosažitelnosti dalších
autonomních systémů (AS). Mezi přenášenými informacemi jsou i údaje o dalších (nesousedních)
připojených autonomních systémech, takže algoritmus může opět sestavit plán (virtuální schéma)
konektivity do mnoha dalších autonomních systémů a může provést eliminaci směrovacích smyček.
Při zahájení spojení se přenesou celé BGP směrovací tabulky obou AS a poté dochází již jen k výměně
změn. BGP má však oproti OSPF méně dynamický charakter a je potřeba jej více konfigurovat a
nastavovat specifické parametry (např. hodnotu cesty) ručně.
V RFC 2283 a RFC 2545 jsou uvedeny rozšíření specifikace k BGPv4 (který je protokolově
nezávislý), aby s jeho pomocí bylo možno přenášet i směrovací informace pro IPv6. Transportní TCP
spojení pro přenos BGP informací může fungovat nad IPv4 i IPv6 a může přenášet libovolné druhy
záznamů.
Následující směrovací záležitosti jsou v IPv6 nové:
- Mechanismus přečíslování směrovačů (router renumbering). Jde o posílání řídících zpráv pomocí
protokolu ICMPv6 (viz dále), které umožňují správci sítě automaticky změnit některé prefixy sítě
na rozhraních směrovačů a zjednodušit si tak konfigurační změny (které se pak promítnou do
směrovacích tabulek a cest).
- Záznam „Hop-by-hop Router Alert“ neboli doplňková IPv6 hlavička, která upozorňuje každý
mezilehlý směrovač, že s obsahem tohoto paketu musí být nakládáno zvláštním způsobem.
Směrovač musí prozkoumat důkladně hlavičky a obsah paketu, zda neobsahují důležitou
doplňkovou informaci a zda není potřeba obsah paketu aktualizovat. Použití této speciální
hlavičky je zamýšleno zejména pro rezervační protokoly (např. RSVP), správu členství
strana 30
v adresních skupinách apod. Pokud paket příznak „Router Alert“ neobsahuje, pak stačí zpracovat
jen úvodní hlavičky a poslat data dále.
Nejrůznější zkušenosti a pravidla pro směrování jsou shrnuta v dokumentu RFC 2546.
2.8.
Servisní protokol
Poměrně značných změn doznal i servisní protokol ICMP (Internet Control Message Protocol)
[12], sloužící k posílání řídících, chybových, testovacích a jiných servisních zpráv mezi uzly sítě
(používán je například nástrojem „ping“). ICMP je v IPv4 i IPv6 považován za integrální součást
sítového protokolu a každý uzel jej musí v plné šíři implementovat. Je úzce propojen s mechanismem
identifikace sousedů (Neighbor Discovery, viz výše).
V nové verzi podle RFC 2463 obsahuje ICMPv6 všechny funkce protokolu z verze 4 a navíc do
sebe pojal funkce protokolů IGMP (Internet Group Membership) a MLD (Multicast Listener
Discovery), sloužících pro řízení a podporu směrování multicastu. ICMP pakety lze dělit do dvou
kategorií – chybové a informační.
Základní chybové zprávy jsou:
- Cílové místo nedosažitelné.
- Vyhrazený čas (počet skoků) vypršel.
- Chybný parametr.
- Příliš velký paket (při překročení MTU některého ze spojů po cestě, v IPv6 novinka).
Mezi informační zprávy patří:
- „Echo Request/Reply“ pro ohlášení přítomnosti uzlu na síti.
- „Multicast Listener Query/Report“ pro podporu skupinových adres.
- „Router/Neighbor Solicitation/Advertisment“ pro objevování sousedů.
Každá z chybových i informačních zpráv může být v jednom z polí paketu dále zpřesněna –
např. „Cílové místo nedosažitelné“ může být zpodrobněna kódem zprávy „K cíli nelze směrovat“,
„Komunikace s cílem administrativně zakázaná“, „Nedosažitelná adresa“ nebo „Nedosažitelný port“.
Protokol MLD (Multicast Listener Discovery,) lze považovat za podprotokol ICMP, i když je
specifikován samostatným dokumentem RFC 2710. Jeho účelem je objevovat okolní uzly, které by
rády dostávaly multicastové pakety pro určitou skupinu (adresu). Takovéto uzly jsou nazývány
„Posluchači/Multicast Listeners“. Získané informace o posluchačích jsou pak poskytnuty protokolu
směrujícímu multicastové pakety (pro IPv4 by to byly například MOSPF, DVMRP nebo PIM, pro
IPv6 jsou ve stadiu příprav). MLD bude využíván zejména směrovači pro zjištění zájmu o odběr
multicastu přímo připojených koncových uzlů.
Ve specifikaci IPv6 je nově zavedeno, že mezilehlé uzly nesmí fragmentovat zpracovávaný
paket, a to ani v případech, kdy to je vzhledem parametrům následujícího spoje (MTU) nutné. Při
zjištění takového problému se odesílateli vrátí ICMP chybová zpráva („Příliš veliký paket“) a je na
něm, aby dále jednal a případně fragmentoval. Pro řídící protokol tak přibyla další činnost - zjišťování
velikosti MTU na jednotlivých spojích přenosové cesty (Path MTU Discovery podle RFC 1981).
Postup popsaný ve standardu je velmi doporučen k implementaci na každém uzlu, protože umožní
využít výhod větších paketů a lépe využít přenosové spoje.
Základní algoritmus je prostý – uzel zkouší vysílat pakety o maximální možné velikosti pro
spoj, kterým je přímo připojen. Pokud mu od některého z následujících uzlů přijde zpráva „Paket příliš
veliký“, musí vhodně snížit velikost paketu a opět čekat na příchod chyb. Proces takto opakuje až do
situace, kdy nepřijde žádná chybová zpráva. Vypočítaná velikost paketu je pak menší nebo rovna než
nejnižší ze všech MTU po celé přenosové cestě. Vzhledem k tomu, že se parametry cesty mohou
v průběhu času měnit (výpadek jedné přenosové trasy, zapojení nového okruhu apod.), je třeba
chybové zprávy očekávat a velikost paketu měnit po celou dobu přenosu – jde o neustálý proces. Uzel,
který vyhledávání MTU implementovat nechce, může na celý proces rezignovat posíláním paketů o
velikosti 1280 bajtů, které musí podle definice IPv6 projít všude.
Může samozřejmě dojít i ke zvýšení MTU a přenosové trase. Uzly tedy mohou čas od času
zkoušet posílat pakety větší, než je současné minimální MTU celé cesty, ovšem měly by tak činit
velmi zřídka, protože se nejedná o pravděpodobnou a častou změnu. Uzly také musí ukončit proces
vyhledávání minimálního MTU, pokud chybové zprávy dostávají opakovaně po dlouhou dobu a musí
se smířit s použitím paketu o velikosti 1280 bajtů. Proces by měl být prováděn jak pro unicast, tak pro
multicast, kde může být z důvodu mnohosti různých cest odhad správného čísla poměrně obtížný.
strana 31
Se směrováním souvisí i záležitosti okolo tzv. multihomingu – připojení lokální sítě do
Internetu více než jedním spojem různých poskytovatelů (multihoming se primárně používá
koncovými sítěmi pro zvýšení jejich dostupnosti při výpadku spoji poskytovatele). Při aplikaci
multihomingu je potřeba řešit problémy adresování uzlů v síti (zda mají mít adresy přidělené prvnímu
nebo druhému poskytovateli), problém výchozího spoje (poskytovatele, přes kterého se bude směrovat
externí provoz), řešení přebírání provozu při výpadku a podobně.
Nejvážnějším problémem multihomingu je růst páteřních směrovacích tabulek Internetu, pokud
tyto sítě inzerují své prefixy přes různé poskytovatele. Prefixy sítí v takovém případě směřují jinudy a
nejdou agregovat. Takový způsob je v rozporu se snahami IETF, které v RFC 3178 specifikuje
doporučený postup multihomingu pomocí IP tunelů, který k růstu směrovacích tabulek nevede. IPv6
přináší navíc výhodu použití více adres z různých prefixů na jednom uzlu (uzly mohou být najednou
součástí více sítí) a volbu zdrojové adresy (lze reagovat na aktuální situaci v síti).
2.9.
Podpora bezpečnosti
Bezpečnost přenášených dat je velmi citlivou záležitostí, často diskutovanou v médiích a na
odborných konferencích. Vyzdvihují se většinou její nedostatky a negativní elementy, poukazuje se na
to, že existuje řada míst v Internetu, kterým odpovídající bezpečnost chybí. Pro některá použití (mj.
rutinní obchodování, bankovnictví) není stávající Internet bez dalších doplňků vhodný.
Z hlediska návrhu architektury nového protokolu ovšem není vhodné přesouvat celou podporu
bezpečnosti do síťové vrstvy modelu. Není vhodné všem aplikacím přikázat povinné šifrování silnými
algoritmy bez ohledu na jejich charakter – některé naopak zabezpečení nepotřebují a přinášelo by to
pro ně zbytečnou režii, snížení přenosového pásma a velkou zátěž pro procesor. Při návrhu
bezpečnostních mechanismů je tedy třeba zvolit vhodný kompromis. Ten se nabízí v odděleném
mechanismu autentizace a šifrování.
Autentizace neboli ověření integrity příchozího paketu je povinné pro všechny implementace a
vytvoří se jím základní bezpečné prostředí, kde by vydávání za někoho jiného bylo velmi nesnadnou
záležitostí. Aplikace se na tuto vlastnost síťové vrstvy mohou plně spolehnout.
Šifrování neboli převedení dat do formy využitelné jedině oprávněným adresátem se použije až
v případech, kdy je aplikace skutečně vyžaduje. Podpora šifrování ve standardech IPv6 pak zjednoduší
implementaci bezpečnostních mechanismů a vytvoří standardní prostředí pro komunikaci šifrovaných
dat, protože nebude třeba implementovat různá proprietární řešení.
Konkrétní mechanismy řešení bezpečnosti již jsou delší čas známy (např. IPsec), nicméně
nebyly povinnou součástí všech implementací. Nedalo se tedy plně spolehnout na zajištění
bezpečnosti na všech spojích v Internetu. Pakety mohly být podvrhovány, měněny a čteny relativně
snadno, takže tíha zajištění zůstávala na aplikacích.
V IPv6 je bezpečnost postavená právě na technologii IPSec (známé už z IPv4) a je povinnou
součástí implementace. Nicméně záleží na aplikacích a konfiguraci uzlů, jestli bezpečnostní
mechanismy použijí, či nikoliv. Není tedy potřeba šifrování nebo autentizaci speciálně implementovat
v aplikacích, stačí použít příslušnou bezpečnostní IP hlavičku.
Základní typy těchto hlaviček jsou dva:
- AH – authentication header (RFC 2402, sloužící k ověření původce paketu, ochraně před
zopakováním odposlechnuté sekvence paketů a ověření jejich integrity – toho, zda nebyly
v průběhu cesty někým změněny. Paket se na zdrojovém uzlu pomocí kryptografických technik
„podepíše“ – vypočte se kontrolní integritní hodnota (ICV), která se uloží do této hlavičky a na
cílovém uzlu se hodnota dalším výpočtem ověří. Přenášená data nejsou šifrována a jsou běžně
čitelná. Používá se jednosměrných (hashovacích) mechanismů SHA a MD5.
- ESP – encapsulation security payload (sloužící pro šifrování paketu, která je zároveň ochranou
integrity, částečnou autentizací a ochranou před zopakováním. Přenášená data za touto hlavičkou
jsou na vysílajícím uzlu zašifrována a po odposlechnutí bez dalších znalostí nečitelná. Cílový uzel
tyto znalosti (klíče) má a data zpět rozšifruje do čitelné formy. Povinné je použití algoritmu DES
v CBC režimu.
AH i ESP spoléhají na nějaký stanovený mechanismus výměny kryptografických klíčů mezi
uzly, například IKE (Internet Key Exchange), SKIP nebo Kerberos, aby mohly spolehlivě fungovat.
Při komunikaci je pak možno použít žádnou, jednu nebo obě hlavičky podle aktuální potřeby aplikace
a prostředí, kde budou data přenášena.
strana 32
Celá bezpečnostní architektura je definována v RFC 2401 a je založena na tzv. „bezpečnostních
vztazích“. Jde o jednosměrné logické propojení mezi dvěma uzly Internetu, v jehož rámci se mezi
nimi vytvoří pomocí AH nebo ESP důvěryhodný přenosový kanál. Bezpečnostní vztah obsahuje jako
své atributy například autentizační algoritmus a jeho klíče, šifrovací algoritmus a jeho klíče, dobu
platnosti klíčů, způsob jejich použití a podobně. Vztah může být buď transportní (paket se pro přenos
opatří doplňkovými hlavičkami a zabezpečena je až část za nimi) nebo tunelový (paket se zabalí do
dalšího paketu a bezpečnostní mechanismy se dají aplikovat na celý zabalený paket).
Vztah je možné vytvořit buď přímo mezi dvěma komunikujícími uzly nebo s využitím tzv.
bezpečnostní brány - prostředníkem mezi důvěryhodnou sítí (Intranetem) a nedůvěryhodným
Internetem. Brána (firewall) přijme zabezpečený paket z nedůvěryhodné sítě, vyjme ho z obálky (ověří
a rozšifruje) a v důvěryhodné síti jej pošle skutečnému adresátovi. Analogicky postupuje při
komunikaci opačným směrem. Při využití bran musí být vždy použit tunelový režim bezpečnostního
vztahu (aby měla brána co enkapsulovat). Brány lze použít například pro vzdálené přihlašování do
Intranetu nebo pro vytvoření virtuální privátní sítě (VPN) spojením více lokalit přes nedůvěryhodný
Internet. Datové přenosy se pak přes něj odehrávají pouze mezi bránami v každé lokalitě a koncové
uzly se o šifrování nemusí starat.
Každé využití některé z šifrovacích nebo hashovacích technik zpomaluje přenos dat, proto musí
tvůrce aplikace rozvážit, jakou bezpečnost pro svá data zvolí a co jí obětuje. Nejnáročnější je šifrování
pokročilými algoritmy (asymetrické, 3DES), nejméně časově náročné je pak použití ověřování.
Výpočetně náročné operace nicméně proběhnou v průběhu přenosu jen dvakrát (na počátečním a
koncovém uzlu). A pokud je přenosová trasa dlouhá, paket získá i jiná zpoždění z důvodu frontování a
zpracování na směrovačích, takže se čas ztracený šifrováním v celkovém zpoždění a přenosovém toku
může ztratit.
Na stávajícím Internetu jsou velmi používaným bezpečnostním prvkem firewally. Je možné, že
bezpečnostní mechanismy v IPv6 obsažené sníží potřebu jejich použití, nicméně existovat budou jistě i
nadále.
2.10. Mobilní zařízení
V klasickém pojetí sítě se počítá s pevně připojenými uzly, které mají stálou adresu a nacházejí
se stále ve stejné síti. Uživatelé ale občas cestují, pracují mimo svou kancelář nebo se baví mimo stálé
místo. A stále více chtějí i v těchto okamžicích přistupovat k datové síti. Ta má již globální charakter a
je do ní možno přistupovat například i bezdrátově, takže se lze zdánlivě bezproblémově připojit „k
nejbližšímu směrovači“. Objeví se ovšem potíže s adresací, směrováním, obousměrnou dostupností
mobilního uzlu a podobně. Řešení lze realizovat pomocí tunelů, vzdáleného přihlášení k domácí síti,
nicméně nejde o ideální postup, který by zaručil, že se mobilní uzel bude moci chovat stejně jako
pevný.
Návrhy na celkové řešení mobility zahrnující automatické přesměrování paketů na novou adresu
se objevily i pro IP verze 4, ale jen jako volitelný doplněk – Mobile IPv4. IPv6 přichází s podobným
pohledem na pohyblivé uzly a navíc mobilitu považuje za povinnou součást implementace. Jaký je
základní princip ?
Přenosné uzly mají vždy přiřazeny stálou adresu v domácí síti, kde fungují stejně jako pevný
uzel. Pokud jsou zrovna na cestách, dostanou ke své domácí adrese ještě navíc cestovní adresu (careof address), která je přidělena z rozsahu sítě, kde se právě nachází. Pro odchozí komunikaci od
pohyblivého uzlu se použije cestovní adresa a se směrováním není problém.
Cestující počítač (mobilní agent) zároveň ohlásí svou aktuální cestovní adresu do domovské sítě
tzv. domácím agentu, což může být například modul na směrovači v domácí síti. Pokud chce nějaký
jiný počítač kontaktovat uzel na jeho domácí adrese (kterou zjistil například z DNS), zastoupí jej právě
domácí agent. Ten eviduje všechny odcestované uzly a zná jejich domácí i cestovní adresy. Příchozí
pakety pro nepřítomný počítač pak domácí agent zachytí a odešle je na cestovní adresu. Cestující uzel
pak pošle původnímu odesílateli zprávu s uvedením své aktuální adresy a další komunikace pak
probíhá přímo mezi dvěma počítači bez prostředníků.
Pokud by původní počítač nebyl schopen aktualizaci vazby zpracovat, posílal by data stále na
domácí adresu. Komunikace by byla poněkud krkolomná (tzv. trojúhelníková, přes domácího agenta),
ale funkční a vyšší přenosové vrstvy by nepoznaly změnu (mobilní uzel by mohl například přejít do
strana 33
jiné sítě a stávající TCP spojení by vydrželo). V IPv6 není trojúhelníkové směrování žádoucí a
schopnost uzlu aktualizovat si adresu protější strany je základním prvkem konceptu mobility.
Pokud uzel mění své místo a tedy i adresu často, může posílat aktualizaci vazby i uzlům, se
kterými nedávno komunikoval, aby se všichni našli snadněji. Vazbu lze aktualizovat i pro směrovač
cizí sítě, kde byl mobilní uzel naposledy hostován (chová se jako jeho pseudo-domácí agent), protože
na něj ještě mohou docházet pakety od neinformovaných uzlů.
Z bezpečnostního hlediska je poměrně riziková aktualizace adresy mobilního uzlu, protože se
tak někdo může vydávat za cizí počítač a získat přístup tam, kde mu nepřísluší. Je proto vždy nutné
používat autentizační nebo šifrovací hlavičku paketu, aby bylo možné odesílatele ověřit. Současně je
potřeba celý mechanismus zajistit proti Denial-of-Service útokům, zaměřené na přetížení
autentizačního mechanismu komunikujícího uzlu.
Mobilní počítač musí podporovat mechanismy automatické konfigurace a objevování sousedů,
aby se mohl v cizích sítích pružně orientovat a správně připojovat. Návrh standardu nedefinuje
mechanismus, kterým uzel dostane cestovní adresu v cizí síti, pokud se k ní připojí – to je ponecháno
správci sítě. Ten může použít například DHCP v kombinaci s nějakým mechanismem jeho pozdější
autentizace, případně povolit přístup až na základě jiných skutečností (zaplacení propojovacího
poplatku a předchozí domluvy) a přidělit adresu pevně. Ideálem je samozřejmě svobodné surfování po
světě a stálé připojení, nicméně překážky k němu budou spíše administrativního rázu.
Technicky je podpora mobility v protokolu řešena doplňkovým parametrem v IPv6 hlavičce
nazvaným „Mobility“, obsahující kód požadavků a odpovědí. Pro podporu mobility byla rozšířena i
sada požadavků a zpráv protokolu ICMPv6 a mechanismus objevování sousedů.
2.11. Kvalita služby
Dalším požadavkem na nový protokol bylo zahrnutí mechanismů pro přenos dat se zajištěnou
kvalitou služby. V IPv4 existuje doplňkový mechanismus Differentiated services, který byl nyní
zahrnut přímo do definice IPv6 (hlavičková položka DS) jako povinná součást. Pracuje s označováním
paketů (nastavením preferenčních bitů v hlavičce paketu). Podle nastavené preference (typu služby)
pak dochází ke zařazení do speciální fronty a s paketem je nakládáno s jinou důležitostí. Čím vyšší
hodnota, tím by s paketem mělo být nakládáno obezřetněji – nízké hodnoty budu mít neinteraktivní
aplikace (pošta), vyšší pak sledované aplikace (http, FTP) a nejvyšší realtimové aplikace (přenos
zvuku a obrazu). U DS nemusí směrovače udržovat stav probíhajících datových toků paketů.
Označení paketu parametrem DS nebo bity v hlavičce se obvykle provede na hranicích sítě a
v jejím rámci už je paket posílán podle předem stanovených pravidel pozornosti (frontování a časování
paketů) na směrovačích. V současné době by mělo být požíváno prvních šest bitů v položce „třída
provozu“ v hlavičce IPv6, pravidla (RFC 2427) stanovují i zachování kompatibility s původním
čtyřbitovým polem IP Precedence v hlavičce IPv4.
Druhým způsobem zajištění kvality služby je rozpoznávání paketů příslušejících ke stejnému
datovému toku, tzv. Integrated services. Jejich cílem je garantovat určité hodnoty přenosových
parametrů (šířku pásma, délku zpoždění, změnu zpoždění a podobně) mezi dvěma koncovými uzly po
celé přenosové cestě. Také IS již byly definovány pro IPv4 jako doplněk (RFC 1633 a RFC 2205).
Tyto služby jsou důležité pro aplikace probíhající v reálném čase (zvuk, video) a pro možnost
garantování určitých služeb zákazníkům od jejich poskytovatelů (sdílení provozu na spojích s předem
určenými parametry). Vychází se z předpokladu omezeného přenosového pásma, kde jednoduché
prioritizování do front podle typu paketu nestačí.
Předpokladem fungování IS je explicitní správa sdílených zdrojů. Jejich správce je přiděluje
datovým tokům na základě požadavků aplikací (pomocí rezervačního protokolu RSVP) nebo předem
nakonfigurovaných parametrů.
Datové toky je nutné nějakým způsobem poznat nebo označit. V IPv6 je k tomu připravená
položka tzv. Flow Label - značka toku přímo v základní hlavičce paketu (viz výše). Směrovač tak
nemusí obtížně zjišťovat příslušnost paketu k datovému toku z dalších skutečností (v IPv4 tato
položka nebyla) a výsledkem je zrychlení provádění operací nad datovými toky.
Význam Flow Label ještě není zcela definován, předpokládá se však, že směrovač může záznam
použít i pro zrychlení směrování. Idea je taková, že prvnímu paketu s danou značkou najde cestu podle
směrovací tabulky, tu uloží do rychlé vyrovnávací paměti a každý další paket se stejnou značkou už
jen přepne na cílovou cestu podle záznamu v této paměti, což je mnohem rychlejší.
strana 34
Rezervace pomocí RSVP musí zajistit:
vyhledání cesty od zdroje k cíli, kde všechny uzly na cestě RSVP podporují,
vyhledání cesty k cíli, která má dostupné požadované zdroje (pomocí modifikovaného
mechanismu směrování podle aktuální zátěže spoje),
- adaptaci na změny cesty při výpadku spoje (RSVP od směrovacího protokolu zjistí novou cestu a
pokusí se rezervovat zdroje i na ní),
- adaptaci na změnu cesty (nezpůsobené poruchou spoje, zahrnuje i aspekt „zmrazení“ jednou
vyhledané cesty tak, aby se neměnila podle aktuálních metrik směrovacího protokolu).
Jde o menší změnu v pojetí směrování - dříve byl každý paket zpracováván odděleně, nyní se
skupinám dat může přiřadit společná značka toku a mohou být směrovačem zpracovávány stejným
způsobem právě na základě této značky. Směrovač podporující IS tedy musí vedle běžných
směrovacích tabulek držet navíc i stavovou informaci o každém datovém toku a jemu rezervovaných
zdrojích.
Jak mechanismus Differentiated tak i Integrated services tvoří společně s RSVP základní kostru
po podporu služeb se zajištěnou kvalitou (RFC 2998). Stanovené parametry jsou zajištěny na každém
směrovači přenosové cesty mezi koncovými uzly, takže jsou garantovány přímo pro obě koncové
aplikace. Důležitou součástí garantovaných služeb je pochopitelně zabezpečení a autentizace, že
rezervaci pásma provádí pouze ten uzel, který smí (např. je z vnitřní sítě, za službu zaplatil, apod.) a že
vyhrazené pásmo využívá pouze on.
-
2.12. DNS – jmenné služby
Asi nejvýznamnější službou je překlad jmenných adres na číselné – DNS (Domain Name
System). Číselné adresy jsou v IPv6 složité a špatně zapamatovatelné, takže není únosné používat je
bez překladu za doménová jména (ani ve zkušebním provozu). Jde tedy sice o doplňkovou, ale nutnou
službu.
Z důvodu zachování jednotného prostředí nebyl řešen jmenný systém jako úplně nový, ale jen
jako doplněk a zobecnění k překladu IPv4 adres (takže zůstane zachována stávající hierarchie od
domén nejvyšší úrovně jako .com, .net, .cz až po subdomény nejnižší úrovně). Dle mého názoru jde o
velmi rozumné rozhodnutí, protož zůstane zachována kontinuita adres pro uživatele, jen se „cosi“
změní pod nimi. DNS se tak stane jednotícím a možná i trochu řídícím prvkem při přechodu Internetu
na novou verzi protokolu. Uzly se budou obracet na něj a podle typu odpovědi se rozhodnou, jak dále
postupovat.
Jak to je řešeno (dle RFC 1886) z technického hlediska ? Stromová struktura jmenných serverů
od domén nejvyšší úrovně přes servery domén druhého a dalších řádů bude stejná jako pro IPv4.
Servery na sebe budou delegovat dotazy stejným způsobem, zůstane i princip prohledávání hierarchie
serverů z IPv4, jen budou mít bohatší databázi záznamů o IPv6 adresy.
Pro dotazy typu „znám doménové jméno a chci znát číselnou adresu“ byl vytvořen nový druh
DNS položky – AAAA (variantně též A6, ovšem s trochu jiným použitím).
K doménovému jménu tak může existovat:
- A záznam s IPv4 adresou (běžně jako dosud),
- AAAA záznam s IPv6 adresou (se stejnou logikou použití jako A).
Přítomnost obou záznamů k jednomu doménovému jménu najednou je možná a v přechodové
fázi bude zřejmě hojně využívaná. Jmenný server pak v takovém případě bude schopen nabídnout
odpověď pro oba protokolové systémy.
Pro reverzní dotazy (uzel zná číselnou adresu a chce znát jmennou), tzv. PTR záznamy, byla
zřízena nová reverzní doména IP6.ARPA (dříve IP6.INT), která funguje stejným způsobem jako
speciální doména IN-ADDR.ARPA pro IPv4. Číselná adresa se tedy rozloží na jednotlivé bajty, které se
v obráceném pořadí a oddělené tečkami položí jako dotaz na adresu v doméně IP6.ARPA. K adrese ve
tvaru FEFE:1234::9876:ABCD tedy získáme její doménové jméno dotazem na PTR záznam
d.c.b.a.6.7.8.9.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.3.2.1.e.f.e.f.IP6.ARPA
Další druhy DNS záznamů (CNAME, NS, MX apod.) zůstanou zachovány. Pokud při své
funkci dále zpracovávají A záznam (týká se např. NS a MX), musí servery v odpovědi vrátit jak jeho
IPv4, tak i IPv6 verzi (pokud existuje). Jinak jejich význam zůstane beze změny.
strana 35
Ve stádiu pracovního dokumentu (draftu) je i návrh na automatické vyhledávání DNS serverů
v síti, jehož smyslem je usnadnit konfiguraci koncových uzlů tak, aby mohly jmenné služby používat i
při bezstavová konfiguraci, bez použití DHCP. Návrh počítá s dvěma úrovněmi automatické
konfigurace DNS. První znamená označení DNS serverů v síti vyhrazenou a pevně stanovenou
lokalitně místní multicastovou adresou, takže tyto adresy bude možné nastavit do implementace IPv6
napevno. Druhá fáze rozšiřuje první o další možnosti automatické aktualizace záznamů v DNS podle
právě používané adresy a různé doplňkové funkce.
2.13. Problémy návrhu
Nový protokol a jeho doplňující služby prošly dlouhým procesem návrhu a zvažování různých
variant mnoha odborníky. Vychází ze zkušeností z provozu celosvětové sítě a respektuje nejnovější
technologické poznatky. Neměl by tedy mít zásadní koncepční chyby. Spor se může vést o nové
rozložení jednotlivých síťových služeb do vrstev (podle modelu OSI).
Existuje názor, že síťová vrstva by měla být co nejjednodušší a starat se jen o přenos v síti. Měla
by implementovat jen služby, které s přenosem přímo souvisí a vše ostatní by měly zajišťovat samy
aplikace (až když službu potřebují) nebo jiné vrstvy. Implementace protokolu potom bude velmi
štíhlá, funkčně nebohatá a jednoduchá. Tento postup byl uplatněn i při vzniku původní rodiny TCP/IP
protokolů.
Druhý postoj je opačný – vrstvy by měly být funkčně co nejbohatší, aby postihly všechny
možné požadavky aplikací na přenos. Funkce musí být v každé implementaci takového protokolu, aby
se na ně mohly aplikace spolehnout. V takovémto prostředí se aplikace vyvíjí o něco rychleji, ovšem
na úkor složitosti síťové vrstvy, která je obtížněji implementovatelná. Tento postup byl uplatněn
například při vývoji OSI protokolů (viz kapitola IP versus OSI v příloze práce).
Při tvorbě IPv6 se přirozeně použil úspěšnější model štíhlé síťové vrstvy. Nicméně za dobu
používání IPv4 protokolu se některé funkce, v síťové vrstvě původně neimplementované, staly tak
masově využívanými, že se musely objevit skoro v každé aplikaci. To je samozřejmě trochu škoda,
protože to znamená práci navíc pro programátory a leckdy řadu proprietárních, vzájemně
nespolupracujících řešení stejného problému. Proč tedy nepřesunout při vývoji nového protokolu tyto
funkce do síťové vrstvy?
V zásadě to možné je a takový přístup byl u některých záležitostí uplatněn (bezpečnost). Mohou
se ale objevit obavy, že obohacováním IP protokolu se dojde k neradostnému scénáři OSI, které bylo z
důvodu složitosti špatně implementovatelné a tudíž neuspělo. Spor se také může vést o to, která služba
je již „standardní“ nebo „většinově používaná“, protože účelů použití sítě je mnoho, a která z nich tedy
má nárok posunout se v síťovém modelu na nižší vrstvy.
U IPv6 se dle mého názoru nakonec zvolilo řešení „něco mezi“ – obohacení o funkce, u kterých
byla široká shoda o jejich praktické použitelnosti. Zbylé služby byly definovány jako volitelné
(například komprese dat), případně ponechány stále na vyšších vrstvách. Můj názor je, že byl zvolen
poměrně rozumný kompromis.
Až práce na implementacích ukáže, zda byl zvolen způsob správný. Dosavadní vývoj je sice
trochu nepříjemný (implementace obsahují jen základní funkce a rozšiřující opomíjejí), to bych ale
přikládal teprve vznikajícímu kódu, mající často jen testovací charakter. Žádný z tvůrců implementací
nepočítá ve finální verzi svého produktu s omezenými funkcemi – současný stav je pouze z důvodů
otestování jádra v laboratorních podmínkách a služby budou (snad) dále doplňovány do základních
instalací IPv6 spolu s jeho dalším rozvojem.
strana 36
3. Přechod z IPv4 na IPv6 – integrace, koexistence
3.1.
O této kapitole
Tato část diplomové práce se zabývá mechanismy přechodu Internetu na IPv6. Vzhledem ke
globálnímu charakteru a důležitosti IPv4 sítě není možné provést výměnu všude najednou a bez
náhrady a zpětné kompatibility. Bude muset být uskutečněna řada navazujících kroků, které mají svá
rizika. Způsobů postupného nahrazování uzlů při zachování jejich plné funkčnosti je více druhů a v
této kapitole jsou podrobněji popsány.
3.2.
Předpoklady přechodu
Správně stanovená strategie a rozpracované postupy přechodu jsou minimálně stejně důležité,
jako návrh a funkce protokolu. Ten může nabízet dokonalé síťové služby, ale pokud nebude jasné, jak
se při zachování služeb aktuální sítě (na kterých dnes závisí mnoho uživatelů a firem) dostat ke
službám novým, nebude vůle novinky nasadit. Situace je totiž odlišná než při vzniku Internetu, kdy
bylo možné počty připojených uzlů zvládnout a přejít na novinky víceméně skokově (k určitému datu
přestat podporovat staré verze).
Nyní by bylo potřeba převést celosvětově rozvětvený a široce používaný Internet s mnoha
návaznostmi, síť která tvoří základ pro elektronickou komunikaci a je bází pro mnoho aktivit, které
zdánlivě s technologií nijak nesouvisejí. Na nový protokol je nutno přejít za chodu sítě, bez přerušení,
protože výpadek služeb by znamenal větší problémy, než absence nových vlastností. IPv4 bude muset
existovat a spolupracovat delší čas s IPv6 společně. Přechod bude pracný a má řadu rizik, která je
nutno zvážit a porovnat s přínosy přechodem získanými.
Pracovní skupiny musí proto vynaložit úsilí i na hledání mechanismů přechodu, integrace a
současné existence obou protokolů. Toto úsilí může být paradoxně pracnější než samotný návrh
novinek na čistém stole – je třeba brát ohled na všechna specifika a nedokonalosti předchozí verze.
Může se zdát jako nadbytečná práce, protože bude použit jen po omezenou dobu přechodové fáze. Ale
z důvodů uvedených v předchozím odstavci musí být mechanismy vypracovány.
V rámci IETF byla proto ustavena pracovní skupina NGTrans, řešící pouze záležitosti přechodu.
Sestavuje mechanismy a doporučení umožňující přejít sítím a jednotlivým uzlům v IPv4 síti na nový
protokol. Stanovuje varianty přechodu a možné scénáře, které při použití některého z mechanismů
mohou nastat. Navržené mechanismy v praxi ověřuje ve zkušební síti 6bone (viz dále).
3.3.
Formy koexistence a přechodu
Pracovní skupina NGTrans vypracovala následující způsoby, kterými je možné postupně přejít
z jednoho protokolu na druhý, aniž by bylo nutno provést náhlou změnu spojenou s výpadkem
konektivity a služeb (protože ty jsou dnes skoro všechny postaveny na IPv4). Z mnoha důvodů je
nutno přecházet po malých částech sítí a ve velmi dlouhém čase, což musí všechny navržené metody
respektovat. Důraz je kladen na neovlivnění chodu současných protokolů, svobodném přidávání
nových implementací a jejich paralelním fungování. Na IPv6 bez podpory původní verze se bude
přecházet až v pozdějších fázích a to plynule – v době, kdy služby verze 4 budou v síti stejně dobře a
po delší čas zajišťovány verzí 6.
3.3.1. Duální protokol
První z možností je zároveň i jednou z pomůcek pro metody další. Jde o implementaci jak IPv4,
tak i IPv6 v jednom počítači, o zdvojení síťové vrstvy. Počítač musí být schopen zjišťovat z DNS
záznamy jak typu A, tak i AAAA a podle vrácené adresy musí použít buď starý nebo nový protokol.
Nemusí jít o kompletní zdvojení celého všech TCP/IP protokolů, ale o hybridní implementaci, kde je
velká část kódu sdílena (a největší rozdíly jsou pochopitelně na úrovni IP).
Každý takový uzel musí mít přidělenu IPv4 adresu, což není ideální, protože přechod na verzi 6
se provádí právě z důvodu nedostatku starých adres. Metoda ale může najít použití na vybraných
uzlech, například jen na serverech, které poskytují služby navenek – pracovní stanice mohou být už
jen na bázi IPv6. Používá se také na všech druzích překladových bran a koncových bodech tunelů (viz
dále).
strana 37
3.3.2. Tunelování
Tvorba tunelů se používá při propojování dvou IPv6 sítí/uzlů přes IPv4 infrastrukturu. V jedné
síti se na uzlu s duálním protokolem enkapsuluje (zabalí) IPv6 paket do IPv4 obálky a pošle přes
klasické směrovače na druhý konec tunelu, kterým je opět uzel s duálním protokolem, který paket
„rozbalí“ a směruje dále nativně v IPv6. Tunel je tedy virtuální dvoubodový spoj a IPv4 se v tomto
případě použije jako další vložená spojová vrstva.
Tunely lze konfigurovat ručně (na uzlech na obou koncích správci nastaví druhý bod tunelu) a
to buď trvale, nebo dočasně (tunely se vytváří jen pro potřebu přenosu). Vhodněji jde tunely
konfigurovat automaticky – například pomocí tunel serveru (RFC 3053). Tunel servery jsou
prostředníci zapojené jak v IPv4, tak v IPv6 síti a obsahují předem nakonfigurované konce tunelů.
Uzel nebo síť, která se chce připojit do sítě s IPv6, si jiným mechanismem (například přes web) zjistí
parametry tohoto konce a u sebe nastaví odpovídajícím způsobem začátek tunelu. Pokud nic nesplete,
může pak přes tento tunel posílat IPv6 pakety do sítě tunel serveru (který je většinou připojen k dalším
sítím). Adresa se koncovému uzlu/síti přidělí z rozsahu tunel serveru.
Další způsob automatického tunelování se nazývá 6to4 (RFC 3056). Principem je existence
ostrovů lokálních IPv6 sítí s hraničními směrovači mezi IPv6 a běžným Internetem. Předpokládá se, že
takovýchto ostrovů s duálními směrovači bude v průběhu přechodu přibývat. Každý z těchto
hraničních směrovačů bude mít vnější IPv4 adresu. Aby nebylo nutno vytvářet mezi nimi speciální
tunely, využije se v cílové adrese paketu speciálního prefixu 2002::/16. Ten je rezervován právě pro
použití technologie 6to4. Dalších 32 bitů za prefixem totiž tvoří přímo původní IPv4 adresa hraničního
směrovače, čímž se vytvoří 48 bitový prefix pro celou síť, jako kdyby byl přidělen poskytovatelem.
Adresace vnitřních uzlů pak probíhá přímo nativně s využitím tohoto prefixu. Uzel ve vnitřní síti
posílá pakety na tyto adresy stejným způsobem, jako kamkoliv jinam. Hraniční směrovač do lokální
sítě ohlašuje, že do těchto speciálních 6to4 sítí zná cestu (zná prefix 2002::/16), takže pakety přijdou
na něj. On pak jednoduše z dlouhé IPv6 adresy vybere 32 bitovou IPv4, na kterou tuneluje daný paket.
Protější uzel pak paket „vybalí“ a dále směruje nativním způsobem.
Alternativní metodou automatického tunelování je 6over4 (RFC 2529). V ní chybí překládající
směrovače – práci s tunelováním vykonávají přímo koncové uzly. Ty zjistí mechanismem identifikace
sousedů v IPv4 síti své IPv6 kolegy (IPv4 síť musí podporovat multicast – opět funguje jako pseudo
spojová vrstva), jejich IPv6 a případně i IPv4 adresy. Nepoužívá se speciální prefix – ten může být
přidělen například od poskytovatele vyšší úrovně.
Ale i v rámci lokální IPv4 sítě bez podpory multicastu mohou existovat IPv6 uzly. Umožňuje to
protokol ISATAP (Intra-Site Automatic Tunnel Addressing Protocol), který používá koncových 64 bitů
IPv6 adresy (určené pro ID rozhraní). Prvních 32 bitů má pevnou hodnotu 0000:5EFE (identifikátor
rozhraní ISATAP) a druhých 32 bitů je přidělená IPv4 adresa. Prefix sítě může být zcela libovolný.
Pokud je adresa paketu z lokální sítě (se stejným prefixem) a je s ISATAP identifikátorem, uzel jej
automaticky tuneluje přes IPv4 na závěrečných 32 bitů. Pokud je adresa z jiné sítě, pošle uzel paket
směrovači. Zjištění informace o směrovači je zatím ve stadiu řešení. Podpora ISATAPu musí být
implementována i na koncových uzlech.
Každá z uvedených tunelovacích metod má určité výhody a nevýhody – každá po uzlech nebo
po síťové infrastruktuře vyžaduje určité vlastnosti. Nicméně umožňuje s relativně malými náklady
koexistovat na stávající infrastruktuře s IPv4. Protokol 6to4 řeší konektivitu vzdálených sítí, ISATAP
a 6over4 pak propojování v lokálních sítích (někdy možná s příliš velkými nároky na multicast). Dle
mého názoru bude velmi užitečným mechanismem 6to4 díky automatickému tunelování přes Internet
s použitím aktuálních IPv4 adres, které se promítnou do prefixů IPv6 sítí. V místních sítích by mohl
najít uplatnění ISATAP, který by byl postupně nahrazován nativní IPv6 lokální sítí.
3.3.3. Překladače
Překladače umožňují komunikaci mezi uzly, které mají implementovánu rozdílnou verzi
protokolu. Překladač je obecně hraniční prvek mezi IPv4 a IPv6 sítí, který převádí hlavičky IP a ICMP
paketů a jejich adresy z jednoho tvaru do druhého podle nějakého předem stanoveného klíče. Uzly pak
nemusí o existenci jiné verze protokolu vůbec nic vědět – překladač je pro přenos dat transparentní.
Překlad hlaviček z jedné verze do druhé nepůjde provést vždy se vším všudy vzhledem k některým
rozdílům mezi protokoly (doplňkové hlavičky apod.) - to už je ale nutná oběť koexistence.
strana 38
Pokud paket dojde na překladač (na jednu z IPv6 nebo IPv4 adres překladači přiřazenou),
hlavičky IP a ICMP paketů jsou mechanismem definovaným v RFC 2765 – SITT změněny na
hlavičky opačné verze a se změněnými adresami poslány dále. Mechanismus záměny adres tak, aby
přenos fungoval v obou směrech, si každá překládací metoda definuje sama.
Jeden z možných způsobů nahrazování adres je na základě dřívějších asociací mezi IPv4 a IPv6
adresou (pokud šel paket jedním směrem a byla v něm nějak nahrazena adresa, při zpětném průchodu
se přiřadí původní adresa zpátky). Dalším způsobem převodu IPv4 adres na IPv6 je tvar uvedený v
podkapitole o adresování duálních uzlů (80 bitů nulových, 16 bitů jedničkových a zbytek je 32 bitová
IP adresa). Podle ní příjemce pozná, že zdrojový uzel o IPv6 není nic, a že odpověď je třeba poslat
zpět přes překladač.
Konkrétní způsob práce překládajících bran je ale různý. Způsob známý už v IPv4 světě – NAT
– je použit i zde, ve variantě NAT-PT (Network Adress Translation – Protocol Translation, RFC 2766).
Směrovač/překladač má přidělen speciální IPv6 prefix, který slouží jako brána do IPv4 sítě. Zároveň
má přiřazen zásobník IPv4 adres, které používá pro mapování vnitřních adres. Pakety od IPv6 uzlu
adresované do sítě se speciálním prefixem překladač „vybalí“ a pošle na IPv4 adresu, kterou zjistí z
posledních 32 bitů IPv6 cílové adresy. Jako zdrojovou adresu použije některou ze svých
zásobních volných IPv4. V opačném směru pak převede podle asociací přidělených adres cílovou IPv4
adresu na správnou IPv6 koncového uzlu ve vnitřní síti a zdrojovou adresu odesílatele převede do
tvaru „speciální prefix+IPv4 zdroje“.
Takovýto návrh by měl obecné nevýhody NATu – neúplná konektivita uzlů ve vnitřní síti,
protože z venku by se nedaly přímo adresovat (bez předem nastaveného mapování). Překladač proto
využívá i DNS dotazů venkovních počítačů k vytváření IPv4-IPv6 asociací. Jak to funguje? Překladač
funguje i jako aplikační brána pro DNS. Když chce IPv4 uzel zjistit A záznam pro určité jméno, tak
překladač DNS serverům ve vnitřní síti pošle modifikovaný dotaz (na AAAA záznam). Vrácené IPv6
adrese přiřadí překladač některou ze zásobníku svých volných IPv4 adres. Tu oznámí původnímu
tazateli a zároveň si vytvoří asociaci - pro chvíli, až bude klient na dotazovaný server přistupovat.
Překlad DNS funguje analogicky i pro dotazy klientů z IPv6 sítě do IPv4, kde překladač vrátí IPv6
adresu se svým speciálním prefixem.
Podobným způsobem jako NAT-PT funguje i TRT (Transport Relay Translator, RFC 3142).
Nepracuje na úrovni IP, ale na transportní vrstvě, kdy se postaví mezi dva koncové uzly, které
komunikují pomocí TCP nebo UDP (ale každý umí jinou verzi). Překladač se tedy pro obě strany bude
tvářit jako ten druhý koncový uzel (přiřadí si jejich adresy v opačné verzi protokolu, než kterou uzly
umí), otevře na obě strany TCP spojení (ne v UDP) a data z jednoho bude posílat do druhého.
Pro mapování adres v TRT se na IPv6 straně použije vyhrazený prefix s délkou /64, do jehož
posledních 32 bitů se vloží IPv4 adresa a na IPv4 straně se použije opět zásobník volných přidělených
IPv4 adres. Konkrétní mechanismus zjišťování těchto adres (aby pakety do IPv4 světa mohly přes
TRT překladač odcházet a obráceně) bude zřejmě vyžadovat opět aplikační bránu pro DNS nebo
obdobná řešení (zatím není upřesněno).
Tato metoda nebude překládat jednotlivé IP a ICMP pakety, ale až celá TCP a UDP spojení
(musí ovšem sledovat ICMP pakety z obou stran, zda nesignalizují nějaký problém nebo změnu stavu
TCP spojení). Očekávanou výhodou oproti NAT-PT je menší počet adresních asociací a možnost
využít stav TCP spojení pro řízení stav asociace (pokud se uzavře TCP spojení, je možné asociaci
zrušit). V NAT-PT při překladu bezstavového IP toto nelze provést, nicméně jeho výhoda spočívá
v překladu veškerého IP a ICMP provozu - je univerzálnější.
U výše navržených překladačů se předpokládá zásobník volných IPv4 adres, což opět není
v souladu s cíli IPv6 (řešení nedostatku adres). Mapování sice nebude nutno provádět v poměru 1:1
(jedna IPv4 adresa pro jednu IPv6 adresu), nicméně každý komunikující uzel do IPv4 sítě ji bude
muset mít. Existuje proto i varianta NAPT-PT, využívající pro mapování i čísla portů protokolu
vyšších vrstev (mechanismus opět známý z IPv4), takže směrem do IPv4 sítě může stačit i jen jedna
adresa pro celou překládanou síť.
Zajímavým způsobem se s přechodem na nový protokol, zejména aplikací, vypořádávají
překladače typu BIS a BIA (Bump In The Stack/API, RFC 2767). Jde o umístění překladače přímo do
koncového uzlu, mezi aplikaci, která umí jen IPv4, a síťovou infrastrukturu na bázi IPv6. BIS je
umístěn mezi síťovou (IP) a spojovou vrstvou. Zachytává IPv4 pakety aplikace, a než je pošle síťové
kartě k odeslání, nahradí IPv4 struktury odpovídajícími IPv6 variantami. Stroj má přidělenu vnější
strana 39
IPv6 adresu a uvnitř ji pro aplikace překládá do IPv4 formy. Totéž provádí i s adresami získanými
jiným způsobem (přes DNS). Stejně tak příchozí pakety a odpovědi konvertuje do IPv4 formy, aby jim
aplikace rozuměla (např. AAAA odpověď převede na A adresu a získaná asociace se použije pro další
komunikaci – jako u NAT-PT). BIA dělá totéž, jen je umístěn přímo v API (aplikační programové
rozhraní pro programátory), které má upravené IPv4 funkce tak, aby navenek produkovaly už přímo
IPv6 výstup.
BIS může najít uplatnění při řešení problémových aplikací, které musí nutně fungovat a které
nebudou v okamžiku přechodu sítě na IPv6 upravené pro nový protokol. Čistějším způsobem je
samozřejmě použití nativních IPv6 aplikací (úpravy starších aplikací by neměly být náročné).
Všechny překladače dle mého názoru naleznou v přechodových fázích využití, zejména pak
s růstem počtu uzlů, které budou komunikovat pouze na verzi 6 (které nebudou mít implementován
duální protokol). TRT se díky svým filtrovacím schopnostem bude používat nejspíš v uzavřenějších a
chráněných sítích. Pokud bude NAT-PT dostatečně výkonné, pak bude nasazováno asi častěji než
TRT, a to díky své obecnosti.
Toto využití by však mělo být jen dočasné. Překladače mají totiž své nevýhody, zejména pak
spotřebu IPv4 adres a neúplnou konektivitu. Tu se snaží odstranit pomocí doplňujících mechanismů
(DNS brány) omezit, nicméně o zcela „čisté“ řešení nejde. Naplnění myšlenky plné konektivity mezi
koncovými uzly tedy dojde realizace zřejmě až v posledních fázích přechodu, kdy bude možno
překladače opět (po dočasném zavedení) odstraňovat.
strana 40
4. Stav implementací dnes a výhled do blízké budoucnosti
4.1.
O této kapitole
Obsahem této kapitoly je přehled skutečně existujících a naimplementovaných protokolů IPv6.
Sleduje praktické možnosti současného IPv6 na směrovačích, v operačních systémech a v aplikacích
na koncových uzlech. Rozsah implementovaných standardů je u každého systému jiný – někde
funguje IPv6 na velmi dobré úrovni, někde jen se základními funkcemi. Při zpracování jsem čerpal
z [27, 33, 39].
4.2.
Implementace v operačních systémech
Asi nejlepší dnešní implementace existuje pro operační systémy BSD unix (existuje jich více
variant). Známý je japonský projekt KAME [30], který nabízí freewarovou implementaci většiny
navržených vlastností a protokolů pro běžné použití. Projekt zahrnuje práci mnoha síťových vývojářů
(zejména z firem Toshiba, Hitachi, Fujitsu, NEC a dalších), kteří společně vytvářejí otevřený sdílený
programový kód pro heterogenní prostředí. Důraz je kladen na velkou stabilitu řešení. Ambice tvůrců
jsou vytvořit a udržovat nejdokonalejší IPv6 implementaci, která by sloužila jako referenční při
aplikaci IPv6 standardů. Její veřejná dostupnost by také mohla urychlit zavádění protokolu na další
platformy a sjednotit neujasněné detaily (které by pak bránily v hladké spolupráci různých
implementací téhož).
KAME obsahuje velmi dobře funkční podporu mobility, bezpečnosti (IPsec, IKE), objevování
sousedů, koexistence, překladů z a do IPv4, tunelování a podobně. Jádro IPv6 je obsaženo ve všech
nových distribucích Free/Net/Open/BSD a zdrojové kódy programů je možno stáhnout zdarma
z Internetu. Výsledky projektu jsou sice primárně používány na platformě BSD, nicméně kód je široce
použitelný (existuje například jeho úprava i netradiční operační systém MacOS X). Součástí projektu
je nejen kód jádra, ale i uživatelských aplikací (viz dále).
Firma Sun Microsystems je v čele vývojářské skupiny, které IPv6 prosazuje, téměř od počátku.
Velmi důsledně proto zavádí podporu do svého operačního systému Solaris. Již pro verzi 7 existují
doplňky (patche), které umožňují připojit se k IPv6 síti. Solaris 8 obsahuje podporu přímo v jádře, i
když zatím není zcela implementovaná bezpečnost (IPSec bude až v další verzi), mobilita a DHCP
konfigurace.
Nicméně pro základní použití je již v Solarisu funkční podpora objevování sousedů, ICMP,
DNS (aplikace BIND), směrovací protokol RIPng a některé další základní funkce. Pro psaní aplikací
je k dispozici základní IPv6 API a pro diagnostiku nástroje jako ping6, traceroute6, snoop6,
netstat6 a nslookup6. Rozšíření podpory o další vlastnosti IPv6 přinese každá další verze Solarisu.
Výrobce nejrozšířenějších operačních systémů pro desktopové stanice Microsoft se
implementováním IPv6 také zabývá. Jako experimentální a nepodporovaný nabízí zdarma ke stažení
doplňkový balík do operačních systémů Windows NT a Windows 2000(SP1) ve dvou verzích
(MSRIPv6 a TPIPv6) a částečně s možností nahlédnout do zdrojového kódu.
Standardní a podporovanou součástí je IPv6 v systémech Windows .NET Server Family a
Windows XP (příkaz ipv6). Podpora není široká a bohatá, nicméně už jde o základní funkční jádro (ne
experimentální implementaci) – sice bez doplňkových funkcí, ale relativně stabilní a s výhledem na
další vylepšení. Obsahuje i podporu multicastu, tunelování, mobility (jen koncového uzlu),
doplňkových hlaviček, objevování sousedů, bezpečnosti na základě definice IPSec (s omezeními ESP neumí šifrovat a není podpora IKE) a další. Chybí podpora dynamického směrovacího protokolu
(není ani RIP), ten by však na koncových stanicích nemusel být potřeba. Podpora IPv6 je tak určena
zejména pro vývojáře aplikací (obsahuje nativní API, které mohou programátoři využívat), použití
v uživatelských aplikacích je omezené (viz dále).
V současné době zatím nejsou plány na oficiální podporu IPv6 v systémech Windows 98 nebo
Windows ME. Majitelé těchto systémů ovšem nemusí být zklamaní, protože existují neoficiální
implementace. Jednou z nich je Hitachi Toolnet6, která ovšem nepodporuje nativní API a je jen
lokálním NAT překladačem z IPv6 na IPv4 (jde o implementaci přechodové technologie BIS). Další
možností je použití programu Trumpet Winsock 5.0, který podporuje nativní API i automatickou
konfiguraci, nicméně nepodporuje směrování, multicast, tunelování a bezpečnost. Licence tohoto
produktu jsou placené a spolu s nízkou funkčností je jeho využitelnost tedy značně omezená.
strana 41
Linux je operační systém vyvíjený s otevřeným zdrojovým kódem (open-source) širokou
komunitou vývojářů. Pro podporu implementace IPv6 do systému vznikla pracovní skupina USAGI
[29] a některé Linuxové distribuce již mají podporu nového protokolu standardně obsaženu. Umí
velkou část funkcí včetně bezpečnosti (mimo tunelového módu), mobility, směrování (mimo
multicastu) a rozvoj jde rychle kupředu. A vzhledem k přenositelnosti zdrojových kódů je možné při
instalaci převzít chybějící části kódu například z projektu KAME a rozběhnout na Linuxu téměř
plnohodnotný uzel IPv6 sítě. Jinou rozvíjející se Linuxovou implementací je francouzká DRET.
Implementace pro operační systémy v určitém rozsahu podpory existuje i od firem IBM (AIX),
Hewlett-Packard (HP-UX), Compaq (VMS, TruUNIX), NOKIA (systém EPOC pro PDA) a dalších.
Domnívám se, že podpora funkcím se bude v dalších verzích rozšiřovat tak, jak budou aplikace a stav
přechodu na nový protokol potřebovat.
Podpora IPv6 v systémech Novell Netware v současnosti neexistuje a do budoucna je nejistá –
firma Novell o ní zatím vůbec nehovoří, nicméně nemohu vyloučit, že se jí už zabývá.
4.3.
Implementace na síťových prvcích
To, bez čeho se žádná rozlehlá síť neobejde – aktivní prvky jako směrovače a různé brány –
musí samozřejmě implementovat IPv6 v první řadě. Většina sítí je dnes vystavěna na specializovaných
zařízeních, pracující s vlastním operačním systémem, takže velmi záleží na postoji výrobců, jak se
k přechodu postaví. Směrovač sice nemusí nutně být přístroj se zvláštním šasi (lze postavit již
zmíněný PC směrovač - běžný počítač s více síťovými rozhraními a směrovacím protokolem),
nicméně bez podpory proprietárních zařízení by bylo nutno oželet velkou část investic do sítí
vloženou. To není schůdným řešením a proto jsou záměry a kroky velkých hráčů na poli směrovačů
bedlivě sledovány.
Firma Cisco Systems začala oficiálně podporovat (po období testovacích verzí) IPv6 dle [41] ve
svém operačním systému IOS od verze 12.2(2)T. Ten obsahuje podporu přenosu po základních
médiích (Ethernet/Fast/Giga, ATM, FDDI, Frame Relay, PPP přes ISDN, sériové linky a další). Umí
směrovat pakety v síti staticky a dynamicky pomocí protokolů RIP a BGP (zatím ne OSPF). Podporuje
IPv6 při použití DNS, podporuje tunelovací mechanismy, objevování sousedů, MTU discovery, SSH
protokol pro verzi 6 a některé další vlastnosti. Jde o velmi solidní základ implementace, nicméně pro
každodenní použití bude nutno počkat na další verze (zejména podpora OSPFv3 a mobility by mohla
citelněji chybět ve větších sítích). Podle plánu přechodových fází Cisca budou další funkce (mobilita,
kvalita služby, hardwarová podpora, OSPF, bezpečnost a multicast) doplněny ve třetí vývojové fázi,
která je naplánována na konec roku 2002.
V dánské akademické síti se na IPv6 páteři používají směrovače firmy Ericsson/Telebit. Umí
RIP i OSPF, multicastové směrování pomocí protokolu PIM, mobilitu, objevování sousedů,
automatické tunelování, filtrování paketů a rezervační služby pomocí RSVP. Z výrobců směrovačů se
dle mého názoru nachází v implementaci IPv6 nejdál.
Kvalitní implementaci na svých směrovačích nabízí firma Juniper. Dobrou implementaci včetně
OSPF má firma Hitachi (využívá kód projektu KAME). Podporu novému protokolu v určitém stádiu
na svých směrovačích uvedly i firmy 6WIND, Nortel, Extreme Networks, Nokia a další. Nejde ale o
plně funkční implementace protokolu, takže jde spíše o příslib do budoucna, že se firma IPv6 vážně
věnuje. V oblasti implementací se dají čekat velké změny kupředu u většiny výrobců a informace
v této kapitole tak zřejmě velmi rychle zastarají (mnou popisovaný stav je z dubna 2002).
4.4.
Stav aplikací
Změny budou muset být provedeny i v aplikacích, které používají uživatelé, minimálně
v místech, kde program očekává vložení síťové adresy. To bude dle mého názoru obtížnější úkol
přechodu na IPv6. Aplikace bude nutné upravit (nebo znovu napsat), nějak distribuovat a instalovat na
všech koncových uzlech.
Musí se změnit části těchto aplikací, kde se pracuje s číselnou adresou, kde se přímo pracuje
s protokoly, jejichž funkce byly přesunuty jinam (ARP), kde se spoléhalo na určitý tvar návratových
hodnot, kde jsou nyní nová omezení na velikosti paketu, fragmentaci a podobně. Zcela jinak se bude
pracovat v multicastových aplikacích, jinak se bude řešit šifrování, jinak se budou připojovat mobilní
uživatelé. V síti budou muset správci sledovat nové skutečnosti pomocí nových monitorovacích
aplikací a jinak budou uzly zajišťovat kvalitu služby pro své přenosy.
strana 42
Na vyšší vrstvy (a tedy i aplikace) mají vliv téměř všechny novinky protokolu.
Aplikace podporující IPv6 je asi největší bolest, zabraňující rychlému šíření protokolu po
celosvětových sítích. Není jich takové množství, které by bylo pro širší používání nového protokolu
potřeba. Výrobci aplikací jej nebudou podporovat, dokud si jej nevyžádá více uživatelů a uživatelé jej
nebudou vyžadovat dokud jej nebudou nutně potřebovat (protože jim IPv4 aplikace fungují). Jde o
uzavřený kruh, ze kterého je možné vystoupit například podporou IPv6 aplikací, i když ještě není
příliš jasný její účel, případně na základě jiných pobídek (viz dále – psychologické aspekty přechodu).
Projekt KAME se nezbývá pouze implementací jádra systému IPv6, ale i úpravou síťových
aplikací. Jde jak o servery (apache, bind, ncftp, postfix, squid, sendmail) tak o klientské aplikace
(VNC, IPv6 doplněk (patch) do webového prohlížeče Mozilla, lynx, wget, perl, CVS a některé další).
Vzhledem k tomu, že úpravy jsou k dispozici ve zdrojovém kódu, je možné aplikace přeložit a přenést
i na jiné platformy, než je nativní BSD Unix. Součástí projektu je celá řada nástrojů pro řízení a
diagnostiku provozu na síti a tyto balíky lze bez obav nasadit do provozu a přímého využití. Pokud by
uživatelé netrvali na svých dosud používaných aplikacích a operačních systémech, daly by se pomocí
aplikací z KAME stavět funkční IPv6 sítě se vším všudy.
Aplikací dostupných přímo pro operační systém Solaris je relativně málo a jde spíš o základní
nástroje - rsh, rexecd, inetd, printing, netstat. Z komplexnějších programů je k dispozici IPv6
Sendmail, tftp a DNS server BIND, což není příliš široké spektrum. Je ovšem možné využít aplikací
dostupných ve zdrojových kódech a přeložit si je přímo pro Solaris.
Důležitou správcovskou aplikací pro unix je také SSH (Secure Shell), která slouží ke
zabezpečenému přístupu ke vzdálenému serveru. Implementace OpenSSH již IPv6 podporuje delší
dobu, a to jak v klientské, tak v serverové verzi.
Windows jsou v podpoře aplikací trochu pozadu za unixem. Jako IPv6 webový prohlížeč je
možno použít i Internet Explorer od verze 5 a výše (u některých verzí bude potřeba doinstalovat
údržbový servisní balík (service pack)), nelze však použít přímý číselný zápis IPv6 adres v URL, ale
jen doménová jména, ke kterým DNS vrátí AAAA záznam. Podporu pro nový protokol mají i
Netscape verze 6 a Mozilla (neustále vyvíjená). Existuje i IPv6 FTP a telnet klient. Z dílny
nezávislého vývojáře pak pochází přenesené, původem unixové aplikace jako apache, cygwin
(emulace API POSIX), ncftp, wget, Emacs, TeraTerm pro přihlášení přes protokol SSH a další.
Stranou nezůstávají ani síťové počítačové hry a na IPv6 je již možno zahrát si třeba Quake.
Šíře aplikací ovšem není veliká a dle mého názoru nestačí ani pro běžného internetového
uživatele. Z často používaných programů dodávaných přímo Microsoftem nelze s IPv6 použít Internet
Information Server a Outlook Express. Je zde velký prostor pro budoucí zlepšení.
strana 43
5. Použití ve světě a v ČR
5.1.
O této kapitole
V této kapitole se budu zabývat popisem sítí, ve kterých je již dnes provozován protokol IPv6.
Ty existují jako laboratorní implementace, akademické projekty a nekomerční zkušební sítě.
Komerční poskytování IPv6 konektivity rutinním způsobem „naostro“ téměř neexistuje.
5.2.
Experimentální a akademické použití
5.2.1. 6bone
6bone [31] je celosvětová zkušební síť organizace IETF, jejímž cílem je testování návrhů,
standardů a implementací v praxi. Neformálně je vedena pracovní skupinou NGTrans. Funguje na
principu IPv6 tunelů přes IPv4 sítě a v plánu má postupně přecházet na nativní IPv6 spoje. Při jejím
provozu se klade důraz zejména na testování přechodových mechanismů.
Pro síť 6bone byl vyhrazen speciální prefix adresy 3FFE::/16, který pak dále distribuuje svým
účastníkům. Adresy z tohoto rozsahu je možné získat připojením se ke stávajícímu účastníkovi 6bone,
použitím části jeho adresního rozsahu a fungováním po dobu alespoň tří měsíců. Poté lze požádat o
přidělení vlastního pseudo-prefixu pro poskytovatele (v rámci výše uvedeného rozsahu), který umožní
připojovat další sítě.
Síť 6bone je největším celosvětovým testovacím prostorem, kde se událostí kolem IPv6
odehrává nejvíce. Pro připojení do 6bone je potřeba vyhradit alespoň jedno zařízení jako přístupový
směrovač a jedno zařízení jako koncový uzel (teoreticky mohou být obě funkce zajišťovány jedním
uzlem, pak se ale mnoho neotestuje). Implementace a použitá platforma směrovače může být
libovolná, měla by však podporovat alespoň základní funkce (alespoň RIPng nebo BGP4+). Je
doporučeno použít implementaci KAME, nicméně 6bone je síť testovací a používat se tedy budou
všechny druhy implementací, které byly napsány – právě pro zjištění jejich interoperability a stability.
Dále je potřeba zaregistrovat svou síť na webovém formuláři 6bone, vyplnit kontaktní a
tunelovací údaje a podobně. Také je nutno mít DNS server, který podporuje alespoň AAAA záznamy
a zřídit reverzní záznam pro svůj adresní rozsah v doméně IP6.ARPA.
Samotné připojení bude realizováno v první fázi nejspíš nějakým druhem tunelu k vybranému
poskytovateli nebo IPv6 síti (od té se také získají adresy k použití). Tu je dobré zvolit co nejblíže
vlastní síti, aby cesta dat Internetem v tunelech byla co nejkratší (tedy nejlépe velmi blízkou síť
stávajícímu poskytovateli připojení do Internetu). Do sítě 6bone je připojena i česká akademická síť
CESNET (prefix 3FFE:803D::/34). Mezi další české účastníky projektu 6bone patří sítě DatronCZ,
PILSEDU, LOGIX a M-SOFT6 – tyto další sítě jsou zatím nevýznamné příspěvky.
5.2.2. CESNET
V České republice je v testování, implementaci a nasazení IPv6 nejdále síť národního výzkumu
CESNET [7,8,28]. CESNET je sdružení českých vysokých škol a Akademie věd, které provozuje
vysokorychlostní síť, na které připojené instituce realizují své výzkumné záměry a která členům
poskytuje připojení do Internetu (nyní zejména IPv4). Mezi akademické projekty patří podpora
distribuovaných výpočtů, videokonferencí, optických sítí, přenos hlasu přes IP sítě, on-line vzdělávání,
přenosové služby se zajištěnou kvalitou a podobně. Jde tedy o ideální prostředí pro nasazení nových
technologií, mezi které patří i IPv6. Existuje proto i pracovní skupina, která se přímo novým
protokolem a jeho rozvojem v akademické síti zabývá. Uzly a sítě na bázi IPv6 se nachází v některých
českých městech a vzájemně jsou propojeny nativními nebo tunelovanými spoji.
Vedle zmíněného zkušebního připojení do 6bone má CESNET přidělen i provozní „ostrý“ IPv6
prefix 2001:0718::/35 (od organizace RIPE NCC), na kterém se nyní odehrává hlavní budování
infrastruktury a připojování uzlů. CESNET je tedy poskytovatelem internetové konektivity i ve světě
IPv6 (rozhoduje o využití zbytku pole NLA) a bude dále členit svůj přidělený prefix na další
hierarchie.
Na přípravě oficiálního registračního centra IPv6 NIC se teprve pracuje, nicméně základní
pravidla již byla stanovena. Další hierarchickou úrovní adresace budou jednotlivá města s přidělenými
/42 prefixy a jednotlivým vysokým školám a ústavům v těchto městech budou k dispozici /48 prefixy.
Tyto rozsahy by měly stačit k dalšímu členění skoro libovolně velké lokální sítě (zbývá 16 bitů pro
strana 44
hierarchizaci podsítí a 64 bitů pro ID rozhraní). V síti CESNET tedy bude moci být 128 měst a
v každém z nich může být připojených 64 institucí.
Mezinárodní konektivita směřuje do celoevropské výzkumné sítě GÉANT v rámci TF-NGN,
což je pracovní skupina složená z představitelů jednotlivých sítí národního výzkumu. Zabývá se sítěmi
nové generace obecně (vysokorychlostní sítě, kvalita služby, MPLS, sofistikované nástroje pro
monitoring a řízení provozu, IPv6 a další témata). Spojení (peering) z české akademické sítě existuje
ještě do sítí Telebit a STU Bratislava.
Jako ISP nebude CESNET zřejmě vykovávat na bázi IPv6 komerční činnost, ale bude tvořit
významnou roli v připojování akademických a výzkumných projektů, které služby nového protokolu a
velký adresní rozsah potřebují. Zájemci z univerzitních sítí se mohou po splnění základních
předpokladů zapojit do práce testovací skupiny CESNETU, která se novým protokolem zabývá. Může
jít například o vytvoření malých laboratorních sítí, které mohou nabídnout ověřování návrhů a
implementací, případně k nim vlastním úsilím i přispět.
Skupina se zabývá hlavně rozvojem IPv6 infrastruktury v rámci sítě CESNET (tunelové a
nativní spoje) a testováním implementací a aplikací na širokém spektru směrovačů a operačních
systému koncových uzlů. Jsou sledovány jak kvalitativní (stabilita, rozsah funkčnosti), tak
kvantitativní (rychlost zpracování přenosu) parametry nového protokolu s ohledem na možné budoucí
nasazení v celém rozsahu sítě CESNET. Vzhledem k celosvětovému stavu IPv6 jde zatím o
výzkumnou aktivitu (a nikoli rutinní službu) sdružení.
5.2.3. Euro6IX, 6NET
Sítě EuroSix a SixNET jsou projekty Evropské komise, na nichž se podílí sítě národního
výzkumu (NRN), dodavatelé internetových zařízení, velké evropské telekomunikační společnosti,
dodavatelé software, univerzity a koncoví uživatelé. Cílem je opět testovat vše okolo IPv6 a připravit
infrastrukturu na ostrý provoz. Jejich provoz začal v lednu roku 2002. Prestižním cílem je vybudování
během tří let největší IPv6 výzkumné sítě právě v Evropě.
Síť 6NET je páteř propojující některé evropské sítě národního výzkumu a testuje IPv6 zejména
v oblasti koncových aplikací (například distribuovaných výpočtů GRID) Speciálně se zabývá
přechodovými mechanismy pro evropské páteřní sítě, národní páteřní sítě a sítě koncových institucí.
Měla by ověřovat směrovací mechanismy, adresní alokaci a mechanismy DNS při použití v nové síti.
Euro6IX je oproti tomu síť propojující primárně evropské telekomunikační operátory a
propojovací body. Její správa je nezávislá na 6NETu (vlastní prefixy) a je komerčně orientovaná. Její
členové jsou výzkumné laboratoře internetových poskytovatelů, kteří si mohou zkoušet různé formy
peeringu, neutrálních propojovacích bodů a řízení různého druhu provozu. Zkouší různá síťová
zařízení a nástroje. Členové sítě se také zaměřují na přenášení a vývoj komunikačních aplikací na
nativní IPv6 protokol. Síť má v kompetenci i řešení právních aspektů s IPv6 spojenými (soukromí,
bezpečnost, svoboda, ochrana dat a podobně).
Obě skupiny mají otevřený charakter a na řadě aktivit spolupracují. Zaměřují se na zkoušení
protokolových implementací, aplikací, nástrojů pro správu, vývoj síťových služeb (mobilita, QoS,
multicast), testování vzájemné interoperability a propojitelnosti. Skupiny řešitelů obou sítí mohou být
společné a budou se na pravidelné bázi scházet a postup konzultovat.
Podpora Evropské komise rozvoji IPv6 a co nejčasnějšímu přechodu na něj je tedy velmi silná –
jak slovní, tak finanční.
5.2.4. Jiné IPv6 projekty
Existuje samozřejmě i řada dalších projektů testování IPv6 sítí, které jsou nějakým způsobem
propojeny mezi sebou a s výše uvedenými sítěmi. Namátkou 6REN a navazující 6TAP (peeringový
projekt), 6LINK, XS-26 (Access to 6 – IPv6), již zmíněný TF-NGN, 6WINIT (zejména pro podporu
bezdrátových zařízení), malé evropské projekty WINE, LONG, BRAIN, Moby-Dick a další. Praktické
pracovní skupiny existují i v RIPE NCC a v mnoha dalších institucích, koordinace různých
vývojářských a implementačních snah probíhá přes IPv6 fórum [32].
V severní Americe není nedostatek adres a potřeba mobilních uzlů tak vysoká, aby akcelerovala
implementaci IPv6 do skutečného provozu tempem jako v Evropě nebo v Japonsku. Je spíše snaha
vybudovat si předmostí a bázi zkušeností pro jeho pozdější zavádění, klíčovým faktorem zavedení
bude spíše potřeba nových služeb pro nové síťové aplikace.
strana 45
Na severoamerickém kontinentu běží akademický projekt Internet 2. Ten neřeší primárně
protokol IPv6, ale rozvoj nové akademické sítě jako celek (včetně infrastruktury, vysokorychlostních
optických páteřních spojů, nových netradičních aplikací, middleware a podobně). Jedna z jeho
pracovních skupin se IPv6 zabývá a řeší tři oblasti – operační (stavba a údržba páteřní IPv6 sítě),
vzdělávací (poskytuje informace správcům nutné pro implementaci IPv6) a motivační (přesvědčování
o strategické výhodnosti přechodu na IPv6). Páteř zatím tvoří čtyři směrovače firmy Cisco propojené
tunely přes IPv4 síť Abilene, prefixy má zatím přidělené jen 24 institucí.
Dalším severoamerickým výzkumným projektem je například TRAIL (je financován organizací
NSF) nebo ESNET (Energy Science Network).
5.2.5. Poskytovatelé zadarmo
Co zbývá jednotlivým uživatelům nebo komerčním firmám, které se do akademických a
výzkumných projektů nemohou zapojit? Pokud blízko sebe nemají komerčního poskytovatele, který
by jim novou konektivitu poskytl (viz dále), mohou využít tunelovacích služeb nabízených zdarma.
Jde o tunelovací servery zmíněné v kapitole o přechodových mechanismech, které jsou dostupné přes
stávající IPv4 Internet.
Mezi nejznámější z nich patří server Freenet6 [40]. Uživatelům stačí nainstalovat protokol do
svého operačního systému IPv6, stáhnout si přes WWW klienta (ten bude tunelovat) a ve formuláři se
ke službě zaregistrovat podobně jako při registraci modemového připojení k Internetu zdarma.
Výstupem formuláře bude i několik konfiguračních údajů (IPv4 a v6 adresy), které uživatel zadá do
nainstalovaného Freenet6 klienta. A veškerý IPv6 výstup z počítače se pak přes tuto aplikaci
zapouzdří do tunelovacích IPv4 paketů a pošle se na adresu tunelovacího serveru. Ten pakety z IPv4
obálky vyjme a posílá je dále v IPv6 síti (nativně nebo s použitím některé IPv4 přechodové
technologie). Pro úplnou funkčnost je potřeba na jmenném serveru vytvořit AAAA záznam pro nové
číselné adresy a vytvořit si pro ně v DNS reverzní záznam v doméně IP6.ARPA.
Tunelovacích prostředníků a serverů je samozřejmě více, namátkou nizozemský IPng,
Hurricane Electric, belgické Wanadoo, italský Bersafe, britský BT Tunnel, brazilská MFA a další.
Někteří poskytují služby jen klientům, kterým poskytují i IPv4 konektivitu, jiní všem libovolně po
světě. Jejich celkový seznam je možné najít např. v [38].
5.3.
Komerční použití
5.3.1. Zahraničí
Mezi první komerční nasazení u ISP patřilo ohlášení operátora Uecomm společně s firmou
Ericsson o nasazení dvouprotokolového přístupového směrovače, který umožnil svým zákazníkům
připojit se nativně v IPv6. Souběžně s ním již rozbíhal svou komerční implementaci poskytovatel NTT
Communications, připojený do uzlů 6TAP, WIDE projektu a dalších sítí. V Asii je výskyt
poskytovatelů nové konektivity zřejmě největší, v Hong-Kongu začal v roce 2001 HKNet, další ISP se
objevili v Japonsku (IIJ – Internet Initiative of Japan) a v Koreji. Objevuje se podpora i velkých ISP,
například firmy MCI WorldCom (síť vBNS+), kanadské Viagénie, StealthCom, ZamaNetworks
(USA), portugalský TELEPAC, švédská Telia, Telecom Italia a dalších. Někteří poskytovatelé tunelů
zadarmo (např. Hurricane Electric) jsou schopni poskytovat i placené služby a nativní IPv6 připojení.
Vybral jsem pouze některé poskytovatele, asi je zbytečné uvádět zde vyčerpávající výčet –
situace se bude měnit každým měsícem, podle postupu testování a stavu implementace na
infrastruktuře, kterou ISP disponuje. Poskytovatel může v rámci zkušební sítě (6bone, Euro6IX nebo
jiné) získat praktické zkušenosti a v okamžiku stability jeho IPv6 infrastruktury může požádat o
provozní prefix registrační autoritu. Od okamžiku jeho přidělení může poskytovat komerční služby
svým zákazníkům podle jejich přání. Čas nasazení se bude u každého z nich lišit, nicméně je jisté, že
nový protokol vzali poskytovatelé na vědomí a nasazují jej podle možností na jejich některých
směrovačích a jiných síťových zařízeních, kterými disponují.
strana 46
5.3.2. Česká republika
Pro zjištění podrobnějších informací o stavu znalostí, testování a implementací IPv6 v České
republice jsem oslovil dopisem deset významných poskytovatelů internetového připojení a všechny tři
mobilní operátory jako nejperspektivnější zákazníky a uživatele IPv6. Text dopisu s otázkami, které
jsem jim všem položil, je uveden v příloze práce, zde shrnuji získané výsledky.
Mobilní operátoři nebyli příliš sdílní, informace považovali za příliš interní na to, aby mi je
mohli sdělit konkrétněji. Obecná vyjádření obsahovala informace o tom, že protokol IPv6 byl vzat na
vědomí a je operátorem sledován. Z názorů byla znát opatrnost k investování do tohoto protokolu a
velké vyčkávání, protože to, že se celosvětový přechod na IPv6 uskuteční, není ještě pro operátory
zcela jasnou věcí. Přechod na IPv6 by znamenal komplikované přeadresování jejich sítě a řada prvků,
které operátoři používají, nový protokol vůbec nepodporuje. Čas ani jiné významnější faktory zatím
operátory výrazněji netlačí. Usuzoval bych tedy o nějaké testovací implementace v laboratorním
prostředí a na zcela nevýdělečné bázi (jen minimální investice vzhledem k velikosti firmy).
V dohledné době nový protokol implementovat nebudou.
ISP byli o něco konkrétnější, nicméně většina zaujala postoj tajemného mlčení („informace
najdete na našich webových stránkách“ kde nebylo o IPv6 zhola nic). Ti sdílnější uvedli, že v rámci
svých možností testují v malých (dvou až čtyřčlenných) skupinkách zavést dostupné implementace,
aby si je mohli „osahat“ pro budoucí použití. Testování probíhá již několik měsíců, přibližně od druhé
poloviny roku 2001. Předmětem testování jsou implementace a aplikace projektu KAME pro systémy
BSD a verze IOSu pro směrovače Cisco. Nejdůležitějšími funkcemi se ukazuje být podpora externího
směrovacího protokolu BGP4+, tunelování a autokonfigurace. Připojení je na bázi tunelů nad IPv4,
pro zákazníky zatím dostupné není (na jejich výslovné přání lze tunelovat do nejbližšího bodu
testovací sítě). Zpoplatnění se očekává spíše až u nativních IPv6 spojů a růstu poptávky zákazníků po
tomto protokolu. Pro tu bude důležitá i existence dostatečné šíře aplikací pro IPv6.
Malá poptávka klientů je také největším důvodem pomalého (resp. nulového) rozvoje IPv6
v sítích poskytovatelů. Zavedení IPv6 jako duálního protokolu na přístupových směrovačích se
očekává do jednoho roku, na páteři pak o něco déle. Nejde tedy o převratné aktivity, ale pomalé
krůčky kupředu. Žádný z ISP, od kterého se mi podařilo získat vyjádření, nijak výrazně nevybočuje
z řady. Poskytovatelé mají zatím přidělené zkušební prefixy vlastní nebo od jejich tunelového
poskytovatele, jejichž sítě jsou součástí zkušebního projektu 6Bone (rozsah 3FFE::/16). Produkční
„ostrý“ rozsah od RIPE NCC (2001::/35) má v České republice zatím přidělen pouze CESNET, který
je s výzkumem nejdál (viz výše). Přidělení trvalých adres od RIPE NCC je ovšem cílem všech ISP,
stejně tak další budování tunelovacích serverů v jejich přístupových bodech.
IPv6 záležitostí v sítích českých (ale i zahraničních) poskytovatelů internetového připojení
zbývá dořešit ještě mnoho, mezi nimi strategie přechodu celé sítě (jaké mechanismy a v jakém čase
budou použity), příprava na požadavky zákazníků a další. Nicméně provedené kroky stále
pravděpodobněji ukazují, že k celosvětovému přechodu na IPv6 snad jednou dojde a že je s ním
potřeba počítat.
strana 47
6. Ekonomické aspekty
6.1.
O této kapitole
Tato část diplomové práce zabývá ekonomickými (a některými dalšími) pohledy na zavádění
protokolu IPv6. Řeší jeho praktické uplatnění, přínosy s negativa pro ekonomiku, trh informačních
komunikačních technologií (ICT), pro poskytovatele připojení, pro jejich zákazníky a pro koncového
uživatele. Analyzovány jsou interní a externí vlastnosti protokolu (SWOT analýza) a kritické faktory
úspěchu (CSF).
6.2.
Jak se může řešení uplatnit v praxi
Praktické uplatnění nového protokolu se nabízí primárně v oblastech, pro jejichž řešení byl
navržen, ale i v jiných. Jde zejména o:
- Růst datových sítí obecně (díky většímu adresnímu rozsahu), což umožní rozvoj komunikačních
příležitostí a rozvoj zatím nevyužívaných služeb (například ASP). Poskytovatelé připojení budou
moci držet krok nabídky komunikačních možností s rostoucí poptávkou po nich.
- Datové sítě mobilních operátorů (díky většímu adresnímu rozsahu a podpoře mobility). Umožní se
připojování všech zájemců o datové přenosy a výrazně usnadní komunikace s nimi.
- Elektronický obchod (díky adresnímu rozsahu a podpoře autentizace a šifrování). Nové služby
umožní vytvořit zajištěnější tržiště a možnost účastnit se obchodu bude mít skoro každý (bez
omezení dostupnými adresami).
- Multimediální přenosy, videokonference, aplikace v reálném čase (díky podpoře kvality služby a
multicastu)
- Zábavní komunikace, on-line hry, peer-to-peer komunikaci (díky adresnímu rozsahu).
- Akademické sítě (díky všem vlastnostem), kde lze v rámci výzkumných projektů využívat veškeré
vlastnosti protokolu a testovat nové.
- Tvorba zajištěných virtuálních sítí (VPN), jednodušší propojování pobočkových sítí (díky podpoře
autentizace a šifrování). Dojde k zpřístupnění technologií pro jejich levné vytváření.
- Rozvoj komunikace drobných a bezdrátových zařízení na společné platformě (díky většímu
adresnímu rozsahu). Jde zejména o spotřební elektroniku, fotoaparáty, klimatizace, zabezpečovací
zařízení, navigační systémy dopravních prostředků a podobně.
- Konvergence datových, zvukových a obrazových sítí (díky adresnímu rozsahu a podpoře kvality
služby) do jednoho univerzálního přenosového kanálu.
- A samozřejmě běžné datové přenosy (jako v dnešním Internetu), ale s usnadněním některých
činností.
Časový plán rozvoje IPv6 si netroufám odhadnout. Kromě sítí některých mobilních operátorů,
některých ISP a akademických projektů není dle mého názoru akutní potřeba použití nového
protokolu. Kritickým okamžikem masovějšího přechodu by mohl být až čas definitivního vyčerpání
IPv4 adres po vyčerpání všech možností, jak je lépe využít (vyvlastňování nevyužitých rozsahů,
nucený NAT/PAT). Ten by mohl nastat během několika let.
6.3.
Jak ovlivní trh ICT a ekonomiku
Zavádění IPv6 bude, pokud k němu dojde, bezesporu velkou událostí na telekomunikačním
(ICT) trhu. Půjde o nahrazení infrastruktury datové sítě novým protokolem. Vzhledem
k celosvětovému rozsahu Internetu a mnohým návaznostem se tato změna projeví i v globálním úsilí.
Někteří odborníci přirovnávají přechod na IPv6 k nedávnému přechodu software na rok 2000,
s několika odlišnostmi. Přechod nemá určený pevný čas a nebude nutno přejít v celém světě najednou.
Ale shodně jako v problému Y2K bude třeba vyzkoušet všechny aplikace a vazby, zda fungují pod
novým protokolem.
Přechod si vynutí náklady navíc u všech migrujících firem a může přinutit předčasně odstavit
některá zařízení před dobou jejich plánované životnosti. Metody přechodu navržené skupinou
NGTrans však umožňují využít stávající zařízení několika způsoby i při práci v nové síti, takže
nepředpokládám doplňkové náklady nijak dramatické. Ty se budou nejspíš týkat nákladů na
personální zajištění přechodu a školení správců. V počátečních fázích přechodu budou potřebovat
koncoví zákazníci zřejmě i odbornou technickou a konzultační pomoc (vypracování studie a
přechodového plánu), která také může zvýšit migrační náklady.
strana 48
Poplatky za software za nové implementace protokolu na koncových uzlech osobně
neočekávám dramatické, spíše v řádu pravidelných údržeb (patches) – tedy zdarma nebo v rámci
širšího programu podpory. Málokdo si zřejmě troufne prohlásit upgrade na IPv6 za zcela novou verzi
svého produktu, spíše bude vylepšení dodáváno v nové verzi s balíkem dalších funkčních zlepšení
(např. jako u firmy Microsoft vložením podpory IPv6 do Windows XP).
Implementace na směrovačích budou mít vzhledem k významu IPv6 pro směrovací software
zřejmě trošku jiný režim, nicméně např. Cisco zatím deklaruje v rámci jedné řady upgradů IOSu (nyní
12.2) podporu pro IPv6 zdarma. Přechod na vyšší řadu již zřejmě bude zpoplatněn běžným způsobem,
tyto náklady se ale budou týkat jen provozovatelů páteřních a větších sítí.
Přímý dopad nového protokolu na ekonomiku bude těžko odhadnutelný. Příchod IPv6 může
pomoci rozpohybovat ekonomiku v oblastech, které nyní nemohly naplno využít svého potenciálu –
tedy v oblasti už zmíněných mobilních sítí a jejich prostřednictvím například mediální společnosti,
obchodní podniky, zábavní firmy a další. Mohlo by se usnadnit obchodování po Internetu. Současně
probíhající konvergence přenosových médií pro hlas, obraz a data by mohla najít jednotné prostředí
právě v IPv6 a zprostředkovaně vést ke snížení cen telekomunikačních poplatků (samozřejmě za
podmínek dokonalé liberalizace a nastavení odpovídajících podmínek státem). Může dojít k velkému
zájmu o dálkovou komunikaci se zařízeními spotřebními elektroniky v domácnosti a podobně. Tyto
efekty mohou být významné nebo jen okrajové – podle poptávky zákazníků.
Dají se tedy očekávat zvýšené výnosy u výrobců implementace IPv6, aplikačního software,
konzultačních firem, provozovatelů mobilních sítí, poskytovatelů obsahu a poskytovatelů služeb
(ASP). Nepůjde o významné změny – ty bych osobně očekával až v navazujících oblastech
ekonomiky (mimo oblast ICT) a až v delším časovém období.
Zavedení IPv6 nemá závratný přímý efekt, jeho význam však spočívá ve vytvoření jednotného
prostředí a platformy pro snadnou elektronickou komunikaci, na níž je možno stavět další služby. Jde
například o urychlení výměny informací mezi podniky mimo oblast ICT, což může vést k úsporám
nákladů nebo zvýšení výroby a výnosů. Dalším příkladem je vzdálené vzdělávání, které zase může
akcelerovat hospodářství zprostředkovaně pomocí dostatku kvalifikovaných odborníků.
6.4.
Jak ovlivní firmy – ISP a jejich zákazníky
V počátečních fázích přechodu budou muset zřejmě nejdříve přejít na (resp. začít koexistovat s)
IPv6 poskytovatelé internetového připojení. Podle volby jejich zákazníků jim nabídnou konektivitu ve
starém nebo novém kabátě. To bude vyžadovat implementaci řady přechodových mechanismů
v přístupových bodech daného ISP a propojení na další páteřní uzly jak IPv4, tak IPv6 poskytovatelů.
Dá se očekávat, že se jim do tohoto prvního kroku nebude příliš chtít, protože pro ně bude znamenat
větší náklady s malými počátečními přínosy. Infrastruktura bude nejdříve nejspíše na bázi IPv4 a IPv6
provoz bude tunelován. S postupujícím časem a přechodem většího počtu klientů zřejmě dojde i
nahrazování IPv4 nativním IPv6 a tunelování ještě zbylého IPv4 provozu v IPv6 paketech.
Sami ISP si zřejmě nebudou moci příliš vybírat – budou se řídit podle požadavků zákazníků.
Provoz na páteřích mezi ISP bude po novu nebo po staru nejspíš podle výhodnosti (který provoz bude
převažovat, který systém bude jednodušší na údržbu, ke kterému budou lepší aktivní prvky a
podobně).
Poptávka po IPv6 konektivitě se dá očekávat (experimentální a mobilní sítě). Poskytovatelé
připojení by se tedy s IPv6 měli seznámit a implementovat jej, co nejdříve to bude schůdné (vzhledem
ke stavu implementací), samozřejmě duálně s IPv4.
Jiná bude situace u koncových zákazníků těchto poskytovatelů, neboli listových sítí Internetu.
Ty nemusí nic nutit k přechodu, ledaže:
- Budou chtít přidělit další globální IPv4 adresy a ty již dojdou. (*)
- Budou potřebovat přímo a hodně komunikovat s jinou IPv6 sítí. (*)
- Budou chtít zajistit mobilitu některých svých uzlů.
- Budou chtít svou síť zabezpečit už na síťové vrstvě.
- Budou chtít používat služby se zajištěnou kvalitou.
- Budou chtít usnadnit konfiguraci koncových uzlů.
Jak padne volba na technologii, která problém řeší? U příčin označených hvězdičkou ani jinou
možnost než IPv6 (nativní nebo nějaký přechodový mechanismus) nemají. U ostatních mohou použít
doplňky k IPv4, nicméně za cenu ne úplně „čistého“ řešení a s výhledem na další nutné změny
strana 49
v průběhu několika dalších let. Komplexním řešením je v tomto případě přechod na IPv6, který
pomůže i u všech ostatních problémů. Přechod se nemusí týkat celé sítě, ale jen vybraných uzlů (např.
na bázi ISATAP).
Konkrétní postup bude záviset na místních okolnostech (malý problém může vyřešit IPSec na
bázi IPv4 bez složité implementace přechodových mechanismů, požadavek na autentizaci a šifrování
podle přání v rozlehlé síti zase lépe zajistí IPv6). Dle mého názoru bude na IPv6 s postupujícím časem
padat volba stále častěji – a pak se dané síti vyplatí připojit se do světa přímo nativně IPv6 a starosti
s přechodovými mechanismy nechat na poskytovateli.
Úspěch a rychlost rozšiřování IPv6 bude tedy hodně záviset na intenzitě výše vyjmenovaných
důvodů. U některých sítí budou velké, jinde malé, někde bude nutné domluvit úpravy i mezi více
sítěmi najednou (podpora nových služeb po celé přenosové trase). Pokud by intenzita důvodů byla
velmi malá, což příliš neočekávám, může dojít i opuštění IPv6 jako takového – prostě jako řešení
dnešních problémů IPv4 nebyl návrh nového protokolu dobrý. Osobně očekávám přiměřenou intenzitu
potřeb (vycházejících zejména z nedostatku adres a malé podpoře mobility ve stávajícím IPv4) a
z toho plynoucího pomalého, leč trvalého rozšiřování IPv6 po světě.
Provozovatel dané sítě se bude rozhodovat podle toho, co pro něj bude momentálně lepší.
Pokud nebude tlačen požadavky uživatelů (interních nebo externích), zůstane u původního stavu a
přejde až se mu vložené prostředky vrátí ve využívání lepších služeb, snadné správě nebo lepší
konektivitě. Rozvahu ekonomických přínosů z možnosti nové komunikace (například z oblastí
uvedených na začátku této kapitoly) musí provést každý správce infrastruktury nebo manažer IS/IT
sám. Přičemž bych se vzhledem ke špatnému stavu implementace a malé poptávce po doplňkových
službách nedivil, kdyby bylo rozhodnutí zůstat na IPv4 ještě dlouho častým případem.
Dovedu si představit scénář, kde část Internetu bude fungovat na IPv6 a část na původní
infrastruktuře po relativně dlouhou dobu vedle sebe. Nebudou-li uživatelé v IPv4 části požadovat nové
služby, postačí jim do IPv6 světa běžná konektivita přes překladové brány. Prostředí Internetu sice
nebude jednotné, mobilitu nebude možno využít na všech místech sítě a nebude fungovat plná
koncová „end-to-end“ konektivita mezi libovolnými dvěma uzly, ale prozatímní potřeby uživatelů
budou naplněny, aniž by bylo nutno vynakládat celosvětově velké výdaje.
Síť však bude mít potenciál postupně přecházet na IPv6 a v okamžiku překonání kritického
bodu (určeného stavem „síť musí přejít, protože většina ostatních sítí, se kterými komunikuje, už také
přešla“) dojde dle mého názoru k opuštění IPv4 velmi rychle. Pak by snad mohl nastat Internet
s takovými základy, službami a v takové podobě, ve kterého ho tvůrci IPv6 navrhli. Nicméně dosažení
kritického bodu může trvat i velice dlouho.
6.5.
Jak ovlivní koncové uživatele
Služby sítí jsou primárně zaměřené na koncové uživatele. Ti s rozvojem nového protokolu
pocítí dvě změny:
- Nepříjemnou, související s technologickými výpadky při aplikaci přechodových mechanismů.
Tyto efekty by měly být minimalizovány a správcem navrženy tak, aby na uživatele dopadly co
nejméně (předchozí testování, upgrade mimo aktivní pracovní dobu). Přechodové mechanismy
tuto zásadu respektují (nasazení duálních protokolů a podobně). Dalším nepříjemným faktorem
může být nucená změna využívané aplikace (protože není pro IPv6 podporována).
- Příjemnou, související s dostupností nových služeb až na koncové uzly. Měly by být dostupné
zabezpečené služby se zajištěnou kvalitou. Uživatelé budou moci na stejné platformě
komunikovat mezi svými mobilními zařízeními a pevnými uzly. Přes elektronickou síť bude
dostupná řada nových služeb (které nyní z různých důvodů nemohly být nasazeny). Všichni se
budou moci bezpečněji účastnit transakcí v elektronickém obchodě. Budou moci přímo
komunikovat s jakýmkoliv jiným IPv6 zařízením bez prostředníků (tedy v rámci jakékoliv
aplikace, například herní). Budou moci snadněji spravovat svá domácí zařízení. Budou moci
přistupovat k multimediálním obsahům tak, že se na ně budou moci v reálném čase
dívat/poslouchat. A usnadní se jim připojování uzlu do sítě, ať již pevné nebo mobilní (díky
automatické konfiguraci).
strana 50
6.6.
Analýza SWOT IPv6
Na úspěchu či neúspěchu zavedení IPv6 a nahrazení stávajícího protokolu se podílí a bude
podílet řada vlastností a faktorů vycházejících jak od samotného protokolu, tak z prostředí, kde by měl
být implementován. Praktické uplatnění a široké rozšíření protokolu není zcela jistou věcí a i přes
možné technologické nadšení z novinek není možné přehlížet překážky. Co všechno může mít podle
jednoduché SWOT analýzy na úspěch vliv?
-
6.6.1. Silné stránky (S)
Řešení nejpalčivějších problémů Internetu, podpora potřebných služeb v základní implementaci.
Nový návrh bez nutnosti respektovat předchozí nedokonalosti.
Návrh s využitím dlouholetých zkušeností s provozem globální sítě.
Důkladná práce mnoha pracovních skupin při návrhu a při testování v praxi.
Otevřený (ne proprietární, ne jednostranný) návrh.
Dobře připravené přechodové mechanismy.
Existující referenční implementace volně dostupné ve zdrojových kódech (open-source).
-
6.6.2. Slabé stránky (W)
Není zpětná kompatibilita s minulou verzí, malá podpora aplikací.
Návrh není dosud zcela dokončen a otestován.
Není možné jej zavést najednou a skokem.
-
-
6.6.3. Příležitosti (O)
Možnost uplatnit se při rozvoji mobilních sítí (díky většímu adresnímu rozsahu a podpoře mobility
uzlů).
Možnost připojovat mnoho dalších zařízení (bezdrátová příslušenství, spotřební elektroniku,
měřiče, senzory, domácí zařízení apod.).
Možnost sjednotit různé síťové protokoly do jediného - zjednodušení správy.
Úspory při nasazování a správě síťových služeb (automatická konfigurace).
Podpora multimediálních přenosů – zvuk, video (díky zajištěné kvalitě služby).
Možnost zavést síťovou infrastrukturu pro podporu veřejných služeb, vzdělávání a zatím
„nezapojených“ odvětví ekonomiky (např. zemědělství).
Usnadnění a rozvoj navazujících služeb (např. Application Service Providers).
Možnost nahrazení některých přenosových služeb nižších vrstev a s tím spojené úspory (např.
nahrazení ATM).
6.6.4. Hrozby (T)
Výrobci směrovačů a aplikací jej nebudou chtít implementovat, nebudou existovat vhodné
aplikace.
Nebude potřeba, nebude vhodným lékem na současné problémy, najdou se řešení jiná (na bázi
stávající infrastruktury). Zmizí nutnost řešit problémy.
Možnost dočasné rozdělení Internetu na dva ne příliš dobře spolupracující systémy.
Investice do stávající infrastruktury nejsou odepsány a bude snaha je využít až do konce
životnosti.
Přechodové náklady budou příliš velké, nákladnost koexistence.
Nedostatek odborníků schopných IPv6 implementovat.
Jak se těmto skutečnostem postavit? Při zavádění je třeba co nejvíce silné stránky a příležitosti
využít a naopak potlačit a odstranit slabé stránky a hrozby. Kritické faktory úspěchu (CSF) vedoucí
k rozvoji IPv6 budou dle mého názoru:
-
Zachování široké podpory vývoje ze strany IETF a některých firem a institucí.
Rychlá standardizace a dokončení rozpracovaného.
Důkladné testování a ověřování novinek
Dokončení implementace pro nejpoužívanější operační systémy.
Důsledná implementace přechodových mechanismů přesně na míru potřebám dané sítě.
strana 51
-
Sledování nových problémů a rychlá reakce na ně (řešení).
Tvorba nových aplikací pro nový protokol a rychlá konverze aplikací stávajících a často
používaných.
Přechod na jednotnou platformu a odstranění duplicitní technologie, pokud už nebude pro IPv6
potřeba.
Nabízení a prosazování konektivity v zatím netradičních oblastech (např. při komunikaci
drobných zařízení – spotřební elektronika, čidla apod.).
Podpora úpravy stávajících zařízení na nový protokol při minimalizaci nákladů.
Propagace výhod a snadného řešení dnešních problémů s pomocí nového protokolu.
Uvedení IPv6 do širokého povědomí odborníků a zainteresované veřejnosti, jejich přesvědčení o
nutnosti přechodu.
To, zda se při řešení problémů současného IP budou tyto faktory plnit, ukáže až budoucí vývoj.
6.7.
Závěry ekonomické části
Po řešení naléhavých problémů IPv4 (adresace, bezpečnost, mobilita, kvalita služby) se volá již
delší dobu (od začátku devadesátých let), nicméně vždy se ukázalo, že potíže lze řešit na bázi stávající
verze jako doplněk, byť s jistými omezeními. Největší problém – malý adresní prostor – je vylepšován
na bázi technologií CIDR a NAT a nejspíše ještě nějaký čas vydrží. Tím je přechod oddalován, což
zpětně vede k tvorbě dalších doplňků k verzi 4.
Otázkou je, kdy bude správa doplňků ekonomicky tak náročná nebo kdy opravdu dojdou IPv4
adresy, že přejít na nový protokol bude nevyhnutelné. Tuto dobu si netroufám odhadnout – neodhadují
ji ani zainteresované instituce (IANA) a odborné odhady se každým rokem opravují a posunují o rok
dále (již od konce 90. let minulého století).
Troufl bych si tvrdit, že protokol nebude primárně zaveden z důvodu technologických - lepších
vlastností, díky kterým na něj všichni dobrovolně přejdou - ale z důvodů ekonomických. Tím mám na
mysli existenci tržní příležitosti (např. skupina uživatelů mobilních sítí, připravených platit za datové
služby nové generace), kterou bude možno využít (proměnit v zisk) jen díky novým technologiím. A
přechod bude uskutečněn, pokud odhad nákladů s přechodem spojených bude nižší než odhad
doplňkových výnosů přechodem získaných (přesná čísla zjistit nepůjde). I z tohoto důvodu očekávám
spíše dlouhou koexistenci obou verzí (sítě, kde se protokol vyplatí, na něj přejdou a sítě, kde se
protokol nevyplatí, zůstanou na verzi 4). Pro jejich vzájemnou komunikaci existuje několik
mechanismů (viz výše), takže by zde neměly vznikat třecí problémy.
Iniciativy a výzvy od provozovatelů mobilních sítí, kteří s nástupem třetí generace
infrastruktury (UMTS) takovéto příležitosti a překážky očekávají, již vzešly (např. společné prohlášení
firem Nokia, Motorola a Ericsson v létě 2000 o urychlení vývoje a implementace IPv6). A možná
právě ty posunuly postoj výrobců síťových zařízení (Cisto, Nortel aj.) tak, že v letech 2001 a 2002
začali IPv6 více podporovat.
strana 52
7. Problémy a prognózy
7.1.
O této kapitole
V závěrečné kapitole teoretické části bych shrnuji některé problémy, na které je třeba při
uvažování o IPv6 nezapomenout. Rád bych také odhadnul časový horizont zavádění a přechodu na
IPv6 v Čechách a v zahraničí. Každý takový odhad ovšem musí být s tuto chvíli nutně nepřesný, zde je
uveden jen pro nastínění časové dimenze.
7.2.
Problémy přechodu a nástin možných řešení
7.2.1. Psychologické předpoklady přechodu
Vzhledem ke komplikovanosti celého přechodu, složitým návaznostem a nutné účasti všech
subjektů, které s Internetem nějak souvisí, musí být k přechodu velmi silné motivy z různých stran. Ty
jsou pro každého jiné a objeví se v jiných časech, což není pro koordinovaný přechod v co nejkratším
čase vhodné.
Jaké mohou být nejčastější motivy pro přechod (podle subjektu) ?
- Výrobci síťových zařízení
• Snaha být první v oboru i za cenu vydání se nejistou cestou.
• Vytvořit prostor pro vznik dalších sítí.
• Najít důvody pro vydání nové řady výrobků.
- Autoři aplikací
• Potřeba využívat nové služby síťové vrstvy.
• Najít důvody pro vydávání nových verzí aplikací.
- Správci sítí
• Potřeba usnadnit si práci.
• Potřeba poskytovat nové služby uživatelům.
• Zvědavost vyzkoušet si novinky.
- Poskytovatelé síťového připojení a síťových služeb
• Potřeba připojovat další velké sítě a zákazníky.
• Potřeba poskytovat nové služby uživatelům.
- Individuální uživatelé sítě
• Potřeba být mobilní, lépe zabezpečený nebo využívat nové služby.
• Možnost tvořit vlastní sítě.
- Podnikoví uživatelé sítě
• Potřeba být mobilní, lépe zabezpečený nebo využívat nové služby.
• Potřeba připojovat další uzly k síti.
- Potenciální uživatelé sítě
• Potřeba být připojen.
Určitě by se daly najít i další motivy. Problémem je, že v současné době (skoro na začátku
přechodu) tlačí motivy jen některé (poskytovatelé služeb) a jiné ponechává v klidu (autoři aplikací). A
bez podpory všech subjektů se bude přecházet jen těžko. Možná bude nutné vedle všech
technologických přechodových postupů přistoupit i k metodám psychologickým (informační osvěta,
přesvědčování a podobně).
Nejsilnější a všem společný motiv, potřeba komunikovat na standardní bázi s ostatními a
využívání síťového efektu, je zatím uspokojována současným Internetem. Nabude na důležitosti, až
bude většina okolních uzlů daného subjektu komunikovat po novu.
7.2.2. Směrovače, páteřní a místní sítě
O opravdovém přechodu na nový protokol bude dle mého názoru možno hovořit až v okamžiku,
kdy bude zaváděn na páteřních sítích a do profesionálních směrovacích zařízení. Laboratorní provoz
s využitím tzv. „PC směrovačů“ (běžný počítač s více síťovými kartami a běžící směrovací aplikací)
může dočasně služby velkých směrovačů (např. Cisco, Nortel) suplovat, ale ne trvale nahradit.
strana 53
Spolehlivost, stabilita a další důvody, pro které jsou používány profesionální zařízení dnes, budou
požadovány i pro nový protokol.
Na páteřních spojích proto bude vyžadována podpora velkých výrobců. Ta se dnes ovšem
rozvíjí pomalu a ne vždy se všemi novými vlastnostmi a vylepšeními. Na neúplných instalacích zatím
nelze stavět nativní IPv6 spoje do rutinního provozu, protože by nebylo možno zajistit plnou stabilitu a
interoperabilitu. A pokud nebudou běžně dostupné nativní spoje, bude nutné při propojování IPv6 sítí
zůstávat při použití tunelů a pomocných mechanismů. Bude se muset brát ohled na vlastnosti a
nedostatky IPv4, což bude situaci v síti komplikovat, navzdory tomu, že protokol byl navržen
s ohledem na usnadnění činností.
Lze proto očekávat, že na rutinní nasazení IPv6 se budou správci chystat až v okamžiku, kdy si
budou jisti stabilní podporou na aktivních síťových prvcích. To je dle mého názoru správný postoj a je
třeba výrobce směrovačů přesvědčit, že jejich příspěvek v podobě stabilní implementace bude
rozhodující. Pokud se budou k problému stavět neochotně, bude nutné vylepšovat řešení na bázi PC
směrovačů a zkoušet je nasazovat i na hlavní sítě. Obava ze ztráty trhů by pak mohla podporu výrobců
znovu přitáhnout.
V místních sítích lze přecházet na IPv6 až se stabilní podporou protokolu v operačních
systémech, které se na síti vyskytují. V řadě sítí se nemusí předpokládat upgrade systémů, které
nebudou podporu protokolu IPv6 obsahovat (například hojně používaných Windows 98), což širší
zavádění protokolu dále oddaluje. Řešením mohou být neoficiální podpory dalších tvůrců, ať již
nahrazující celý IP zásobník, nebo BIS/BIA implementace.
Společným problémem jak u páteřních, tak i místních sítí by mohla být finanční nákladnost
s přechodem spojená. Bude nutné zakoupit nové licence produktu, strávit čas pracovníků instalací a
školením uživatelů a toto všechno stojí peníze. Jestliže ze změny nebude mít daná organizace nějaký
přímý efekt, budou velmi váhat prostředky uvolnit. Navržené přechodové metody naštěstí umožňují
finance vynakládat postupně, podle aktuálních potřeb a možností.
Řada návrhů není v současné době úplně dořešena a standardizována. U těch důležitých se nedá
předpokládat, že se začnou zavádět ještě před jejich oficiálním ustálením, takže čekat bude možná
nutno i z tohoto důvodu. Programátoři a správci se musí nejdříve s novými technologiemi seznámit,
otestovat, získat jistotu v jejich aplikaci a teprve až potom je mohou rutinně zavádět. IETF nicméně na
standardizaci nehotových záležitostí pracuje stále a bez přerušení.
Dlouhá současná existence obou protokolů bude klást zvýšené nároky na správu dvou prostředí,
zajišťování různých vztahů mezi nimi a podpory více sad stejných aplikací a služeb. Může dojít
k dočasnému „rozdělení“ jednotného Internetu, kdy některé služby nebudou mezi IPv4 a IPv6 sítěmi
dosažitelné, protože nebude ochota je podporovat dvakrát. Vždy by ale měl být k dispozici
mechanismus, který bude schopen alespoň nouzově překládat provoz a domluvit se s nepodporovaným
světem. Mnohé také může usnadnit společná nebo velmi podobná administrace obou verzí, kdy budou
změny v jedné části automaticky překlápěny do druhé.
Může se také stát, že některé organizace budou potřebovat přejít velmi rychle (např. sítě
mobilních operátorů), zatímco sítě poskytovatelů obsahu budou chtít vzhledem k nákladům přejít až
co nejpozději. Dá se očekávat velká datová zátěž mezi těmito sítěmi, což bude prubířským kamenem
pro odolnost a škálovatelnost tunelovacích a překládacích mechanismů.
Může to přinést
nepříjemnosti, které se projeví i uživatelům zhoršením kvality jejich služeb. Taktéž implementace
novinek může přinést nutné technologické odstávky některých uzlů, což mohou nést jejich uživatelé
nelibě. V této souvislosti jsou pozitivní duální mechanismy, které vedle sebe nabízí paralelně obě
verze – zejména u často využívaných služeb by jejich správci měli přemýšlet o provozování stejného
obsahu pro každý protokol zvlášť.
Komplikace mohou nastat i při implementaci dalších přechodových mechanismů na síťové
vrstvě (tunelování a překládání). Ty budou sice dobře ozkoušeny z laboratorního testování, nicméně
v provozu naostro se mohou ukázat jako málo výkonné nebo náchylné k častým výpadkům. Vazby
mezi různými prostředníky, tunely a překladovými bránami se mohou ukázat dalekosáhlejší - bude zde
možnost, že dojde ke špatnému nakonfigurování tunelu nebo brány a k ovlivnění jiných systémů, které
se mohou ocitnout dočasně bez konektivity.
Pokud jsou některé stávající IPv4 služby nasazené nestandardním způsobem, nemusí je
překladové mechanismy vůbec brát v potaz. Pokud správci nebudou mít o přechodových
strana 54
mechanismech dostatečnou vědomostní základnu, mohou pak být překvapeni nefunkčností svých
životně důležitých služeb a z toho plynoucím zmatkem.
DNS je asi nejvýznamnější aplikační službou nutnou pro zavedení protokolu. Samotná integrace
IPv6 adres do IPv4 hierarchie není problém, protože jmenný systém zůstane zachován a bude tvořit
spojovací článek mezi oběma protokoly. Potíží by mohla být právě správná integrace – na kterém
protokolu má služba fungovat a jaké záznamy má vracet, pokud budou obě verze na výběr. Pokud
bude v DNS hierarchii nad sebou několik serverů s různými verzemi protokolů, bude třeba pro
neporušitelnost doménového stromu nějak zajistit předávání IPv6 záznamů i přes IPv4 servery a
překládání dotazů sestavených pomocí jiných protokolů do korektní verze pro další podřízený nebo
nadřízený DNS server. Půjde o další kritické místo v síti, o které je potřeba se starat a monitorovat
jeho funkčnost, protože výpadek DNS znamená v IPv6 (a často i v IPv4) výrazné omezení použití sítě
(adresy v číselném tvaru si je pamatuje jen velmi málo uživatelů).
Bezpečnost jako velmi důležitá a mediálně sledovaná otázka již byla zmíněna. Její zlepšení je i
jedním důvodů tvorby nového protokolu. Nicméně jako u všeho nového a v praxi netestovaného, může
zavádění IPv6 přinést zatím netušené bezpečnostní hrozby a slabá místa (jak z důvodu opomenutí při
návrhu, tak z důvodu chybné implementace), která bude nesnadné ochránit. Člověk je tvor vynalézavý
a zkušenosti z dnešních síti hovoří o tom, že útočník je při hledání a využívání slabin systému velmi
důkladný. Řešení se nabízí v pečlivém a trpělivém testování a zvýšeném dohledu v počátečních fázích
implementace.
A velkým problémem bude, pokud nebudou naplněny samotné předpoklady přechodu (viz výše)
– že se zainteresovaným nebude chtít měnit stávající infrastrukturu při vidině nutné velké práce a
velkých financí. A že budou raději hledat doplňková řešení k současnému stavu, než implementovat
komplexně nový návrh, byť možná lepší.
7.2.3. Koncové uzly a aplikace
Vedle implementace protokolové rodiny IPv6 do operačních systémů budou muset uživatelé
přejít na nové verze svých aplikací – ne vždy může být k dispozici ve stejné chvíli, jako bude
přecházet jeho domovská síť na IPv6. Ne všechny aplikace jsou udržované a původní autor nemusí
jevit zájem na vytvoření nové verze.
Na koncových uzlech budou muset být v průběhu přechodu dlouho oba dva protokoly. Jejich
vzájemnou interakci a spolupráci je třeba pozorně sledovat, aby duální implementace nezpůsobovala
nestabilitu systému. Dvojakost může mást uživatele („proč to z téhle aplikace funguje a z jiné ne“),
bude vyžadovat náročnější správu, hledání problémů a podobně. Duálnost je třeba zajistit na
zařízeních v celé síti včetně nutné administrativy (dokumentace, smlouvy o propojování), takže půjde
o časově velmi náročnou činnost. Neuvážený časný přechod na IPv6 se proto může ukázat nevýhodný,
protože daný subjekt (síť) s sebou zbytečně dlouho ponese nevýhody dvojího protokolu, aniž by je
více využil. V rámci jedné instituce by tedy měl přechod být co nejrychlejší, což vzhledem
k současnému nedostatku aplikací a nativní konektivity zatím nelze realizovat.
Konkrétní mechanismy spolupráce aplikací obou protokolů na jednom počítači zatím neexistují
(a ani pro celou šíři aplikací existovat nemohou). Soužití tedy bude muset řešit správce až podle
aktuální potřeby a snášenlivosti aplikací s jinými využívanými službami. Teoreticky by mělo být
bezproblémové, záleží ovšem na kvalitě napsaných programů (např. zda důsledně dodržují vrstevnatou
architekturu, zda nevolají přímo služby nízké úrovně apod.).
Pro úspěch IPv6 bude velmi rozhodující právě podpora aplikacemi. Instalovaná báze IPv6
aplikací bude dle mého názoru postupovat pomaleji než instalovaná báze IPv6 implementací na
směrovačích a operačních systémech. Jistým hybným prvkem by se mohl stát vývoj v rámci komunity
open-source (vyvíjející programy s otevřeným zdrojovým kódem), motivované snahou vyzkoušet si
novinky v praxi. Jejich výsledky mohou pomoci inspirovat se ostatním, jak implementační problémy
řešit, případně od nich řešení přímo převzít.
Z aplikací půjde nejčastěji o webový prohlížeč, poštovní klient, nástroje na přenos souborů a
program na vzdálené přihlášení. V těchto oblastech se dá čekat velká podpora výrobců současného
software a malé problémy (jde o široce používané programy, velký počet uživatelů a firmy mají
obchodní zájem na udržení a rozšíření počtu klientů - uživatelů). U nich by mohl přechod nastat rychle
a bez problémů.
strana 55
Potíže by mohly nastat u okrajových aplikací, na míru psaných podnikových řešení a aplikací
s uzavřeným zdrojovým kódem, kde autor nebude motivován k úpravám. Zde pak bude nutno použít
některou z technologií BIS nebo BIA, které budou takovéto „zapomenuté“ aplikaci simulovat její
domácí IPv4 prostředí, i když už všude kolem bude dávno IPv6 síť.
Využívání nativních vylepšení tohoto protokolu se v aplikacích objeví zřejmě až v pozdější fázi
a až u nových aplikací napsaných přímo na míru například mobilnímu telefonu.
7.3.
Prognóza
V této kapitole se pokusím odhadnout budoucí vývoj a možný úspěch protokolu IPv6
v následujících letech. Předpovídání a časové odhady jsou ve světě informačních technologií velmi
ošemetnou věcí. Stav poznání se vyvíjí velmi rychle, stejně tak jako potřeby uživatelů/zákazníků sítě a
stejně tak tržní prostředí (které zase odráží potřeby a přání většiny obyvatel). To, co se zdálo jasné
včera, vůbec nemusí mít úspěch zítra. Může se objevit jiné technologické řešení, může zmizet potřeba,
která si novinku vynucovala, lidé mohou změnit své pojetí práce s datovými sítěmi. V neposlední řadě
je třeba sledovat výkyvy světové ekonomiky, rozhodnutí vlád významných zemí, stav válečných
konfliktů nebo jiných civilizačních hrozeb (terorismus).
7.3.1. Rozšiřování IPv6
Čas rozšíření po světě je asi nejvíce nejistou veličinou. Vzhledem k tomu, že má jít spíše o
postupnou evoluci, než o skokové nahrazení minulé verze, bude přechodové období dlouhé. Na jednu
stranu je to dobře – umožní se všem zúčastněným přizpůsobit si přechodový plán co nejlépe své
organizaci, umožní náklady přechodu rozpustit do delšího období, umožní postupně získávat
zkušenosti a odladit v klidu počáteční chyby. Na druhou stranu to dobře není – bude nutno udržovat
dvě infrastruktury, sledovat vazby mezi nimi, nebude možno v této době plně využívat nových
vlastností, mohou vznikat problémy domluvit se z jednoho světa do druhého a podobně.
Dle některých názorů z firem IBM a Compaq [20] bude přechodová fáze (od počátku
komerčního využívání IPv6 až po ukončení poskytování IPv4 služeb) trvat minimálně patnáct let.
Může se to zdát dlouho i krátce, pokud se na to podíváme z obou pohledů (náklady na duální protokol
a ponechání času na přípravu přechodu). Můj osobní názor je, že nejde o nijak přehnaný odhad,
přechod bude v některých oblastech (s dostatkem IP adres, bez nutnosti nových služeb, s novou IPv4
infrastrukturou) velmi pomalý. Nucené urychlování by se nemuselo vyplatit, subjekty by mohly hledat
postraní cestičky, které by výsledku neprospěly (např. hromadné nasazování nekompletních
implementací). A do dosažení zlomového bodu (kdy většina ostatních sítí bude na IPv6) ani větší
„nutící“ mechanismy existovat nebudou.
Nabíhání nového obsahu (např. webových serverů) na IPv6 síti bude jen pomalé. Cílové
skupiny uživatelů dnes existují výhradně na IPv4 infrastruktuře a nový protokol je spíše záležitostí
technologických nadšenců, než skutečnou platformou (doufám, že jen zatím). Poskytování obsahu na
duálním protokolu tak bude zatím otázkou prestiže „jsme první v implementaci nových technologií“,
než podle skutečné potřeby uživatelů obsahu. K překlápění na novou platformu zřejmě dojde až
s přechodem celých sítí, případně ad hoc podle zátěže (pokud bude většina paketů tunelovaných nebo
překládaných, bude možná dobré uvažovat o snížení nároků na procesorový čas).
Zde také vidím největší možný obtíž rozšíření – IPv4 sítě budou spokojeně fungovat na stávající
bázi, nové IPv6 na té své. Pokud je nebude něco nutit ke sjednocení (třeba poptávka po nových
službách nebo neudržitelné mechanismy překladu), mohou vedle sebe koexistovat dlouho. Nedojde-li
totiž k přechodu sousedních sítí, nebude muset přejít ani daná síť, která je zase sousedem pro další sítě
a tak stále dokola. Přechod bude možná potřebovat k urychlení impuls ze světa mimo informační a
komunikační technologie – třeba dramatické rozšíření mobility obyvatelstva nebo náhlý nárůst obav o
bezpečnost přenášených dat. Pomoci by také mohla existence nějaké rozhodující „killer“ aplikace (dle
anglické terminologie), neboli služby na bázi IPv6 žádoucí pro mnoho uživatelů, která by je
k platformě dokázala přilákat. V první fázi přechodu tak půjde spíše o investice do budoucna a
strategická rozhodnutí s cílem vyhnout se časovému tlaku ke konci přechodu, ne o investice s přímým
a okamžitým ziskem.
Po přechodu nezanedbatelné části Internetu na IPv6 bude pro správce staré infrastruktury čím
dál tím výhodnější přejít také. Vzhledem k volnému časovému plánu to mohou spojit s jinými
zlepšeními, které na své síti budou provádět (např. se změnou topologie, přečíslováním nebo
strana 56
přidáváním dalších uzlů). Spojení více rozvojových aktivit by mohlo zlevnit náklady na přechod a
uspořit čas změnou strávený, což posune hranici rozdílu „přínosy z přechodu - náklady“ v uvažování
odpovědných osob do výhodnějších pozic.
Rozšíření po ČR bude v úzké souvislosti s celosvětovým přechodem, zde bych neviděl velké
rozdíly mezi jednotlivými částmi světa. Půjde tedy (opět velmi hrubým odhadem) o patnáct let (viz
výše) současné koexistence nabízených služeb. Požadavky budou nejdříve přicházet od subjektů, kteří
by rádi připojili a adresovali své velké interní sítě – například mobilní operátoři (zatím tyto požadavky
nejsou). Poskytovatelé internetového připojení mohou od jisté doby začít nabízet IPv6 konektivitu a
později na ni převést i své páteřní sítě.
Rozhodujícím momentem však bude poskytnutí zahraniční konektivity z ČR ven na nativní
IPv6 bázi od poskytovatelů mezinárodního spojení (např. GTS/KPNQwest). Těch je výrazně menší
množství než koncových ISP a bude ně mít velký vliv. Pro ISP pak bude výhodnější přejít na IPv6
nativně také a začít IPv4 na páteřních sítích tunelovat. Změny na páteři se mohou odehrát poměrně
rychle a bude záviset nejvíc na dohodě se zahraničním partnerem.
Tento stav vydrží dle mého názoru delší čas a během něj budou koncové sítě pomalu a postupně
podle potřeby na nový protokol přecházet. V závěrečné fázi je pak velké fixní náklady na IPv4
infrastrukturu (bude ji využívat jen málo zákazníků) mohou přinutit k motivování zákazníků, aby
přešli na IPv6 také. Motivace může mít podobu nabídky pomoci při rekonfiguraci zákaznické sítě,
zvýšení poplatků za IPv4 připojení, zdůrazňování výhod nových služeb a podobně.
A kdy celý proces přechodu může začít ? Striktně vzato už začal, první komerční implementace
a poskytování služeb již existuje. Optimisticky bychom se tedy mohli dočkat ukončování přechodu
ještě před rokem 2017 s velkou částí převedené sítě už v roce 2009. Pesimisticky bychom mohli
očekávat dokončení až ve dvacátých letech tohoto století. Je zřejmé, že odhadovaná doba je příliš
vzdálená a téměř jistě dojde k nějakému obratu ve vývoji, který při současných znalostech nemohu
předvídat. Výše uvedená léta jsou tedy víceméně sázkou do loterie – další mezi mnoha jinými, určitě
kvalifikovanějšími odhady.
7.3.2. Uživatelský a tržní úspěch
Bude mít IPv6 úspěch? Bude Internet budoucí generace fungovat právě na tomto protokolu?
Přikláněl bych se ke kladné odpovědi, i když na druhou stranu bych zabrzdil možné nadšení, které by
u někoho novinkám nakloněného mohlo vzniknout. Protokol je dobře navržen, stojí na dobrých
základech a přináší užitečné věci. Většinu uživatelů ale nebude příliš zajímat univerzální návrh, který
spoustu věcí v síti usnadňuje a řeší komplexně. Je zajímá spíše konečný efekt – co budou mít z nového
protokolu oni. Pokud budou výhody zanedbatelné nebo nepřijdou v rozumné době, může u nich
vzniknout dojem, že celá změna byla zbytečná a stála je zbytečně mnoho času a peněz.
Osobně si myslím, že zjišťovat uživatelský úspěch protokolu není příliš rozumné. Jde o poměrně
nízkoúrovňovou záležitost, jejíž hlavní výhody oproti předchozí verzi se projeví až zprostředkovaně
v aplikacích, v navazujících produktech. Uživatelé se mohou dozvědět, že kvalita a použitelnost nové
aplikace mohla být umožněna jen díky IPv6, ale přínosem pro ně bude až ta aplikace. Zavedení
protokolu by tedy nemělo být poměřováno okamžitým uživatelským úspěchem, ale spíše technickými
měřítky (zdali nakonec infrastruktura dělá věci, pro které byla určena a zdali je dělá správně).
Z uživatelského hlediska by mělo být hlídáno jen to, zda k novinkám není z jejich strany apriori
záporný postoj (zda uživatelé nepřichází o část funkčnosti, zda je změny nepřipraví o něco, na co byli
zvyklí).
Ovšem měřítko, které by aplikováno být mělo, je tržní úspěch - to, zda jej budou výrobci
implementovat, správci sítí kupovat a programátoři v aplikacích využívat. V tomto úspěchu se bude
odrážet i vliv aplikací a služeb, které novou infrastrukturu potřebují. Pokud bude panovat všeobecná
shoda o dobrých vlastnostech protokolu a že tedy jde o „budoucnost Internetu“, budou o něm osoby
odpovědné za nákup a implementaci uvažovat jako o řešení. Budou ho následně požadovat po
výrobcích aktivních prvků a po programátorech budou chtít jeho podporu v aplikacích.
Implementace IPv6 tak bude žádanou službou, za kterou budou firmy ochotny utratit nějaké
peníze – ať už z přesvědčení, že jim protokol bude přínosem, nebo z nutnosti, protože nebude jiné
alternativy. Pokud tedy budou IPv6 aktivity generovat firmám nezanedbatelný obrat, bude to známka
toho, že se pro úspěšný přechod Internetu na IPv6 dějí ty správné věci.
strana 57
IPv6 zatím nemá vážnějšího konkurenta, který by řešil problémy IPv4 alespoň tak, jako se snaží
šestá verze. V pracovních skupinách IETF se při volbě řešení uvažuje převážně již jen o IPv6, nebo o
„dolepování“ vad stávajícího protokolu různými doplňky, ovšem s mnoha koncepčními nedostatky.
Pokud přesvědčení o vhodnosti protokolu IPv6 nevznikne, budou se subjekty zdráhat do něj
investovat – budou čekat, až jak situace dopadne. Neúspěch IPv6 by znamenal krok zpět – muselo by
se hledat řešení jiné a musely by se analyzovat příčiny neúspěchu (zejména proč jej odmítli správci
stávající infrastruktury). Zřejmě by se nemuselo začínat úplně z čistého stolu, ale řada vlastností by se
musela přepracovat – a přechodové mechanismy jako nejcitlivější faktor úspěchu zvlášť.
Osobně si jiné řešení než IPv6 nedovedu v současnosti představit. Myslím, že povědomí a
přesvědčení (zmíněné v předchozím odstavci), že jde o vhodné řešení, už vzniklo a pomalu roste.
Napomáhá mu také podpora některých institucí (Evropská komise, akademické organizace, někteří
výrobci síťových prvků), která mu dává punc oficiality a jistoty – že jde o řešení, do kterého je možné
investovat bez obav z návratnosti v budoucnu.
strana 58
PRAKTICKÁ ČÁST
strana 59
8. Registrace sítí
8.1.
O této kapitole
V této části práce se budu v krátkosti zabývat stavem, způsoby a podmínkami registrací IPv6
adres a sítí u odpovědných autorit. Důraz jsem kladl na praktické použití pro registraci případné
budoucí sítě VŠE a úspěšně se mi tak podařilo registrovat jeden ze zkušebních prefixů.
8.2.
Podmínky a průběh registrace
8.2.1. Obecné skutečnosti a zásady
Jedním z faktorů, na které se při vytváření adresního systému IPv6 hledělo, byl zvládnutelný (co
nejnižší) počet záznamů na směrovačích v páteřním Internetu (bez nastavené implicitní cesty, tzv.
„default-free“ oblast). Cílem bylo vyhnutí se problému, který nastal po rozsekávání sítí na velmi malé
kusy v IPv4 a růst páteřních směrovacích informací (viz kapitola o problémech IPv4 a jejich
částečných řešeních).
Byl proto přijat princip jemnějšího členění prefixu IPv6 adresy na další podpoložky, které by
agregaci usnadnily. Vychází se z hierarchické a víceúrovňové struktury poskytovatelů internetového
připojení (což nemusí nutně znamenat stromovou topologii Internetu !). Každá z těchto úrovní má
vyhrazený určitý počet bitů adresy pro potřeby svého členění. Na vrcholu struktury je globální
agregátor (TLA, top level aggregator), který dostane přidělen velmi krátký prefix. Dalších několik bitů
adresy za prefixem využije k přidělování delších prefixů poskytovatelům různé velikosti (NLA, next
level aggregator). A tito ISP opět využije další bity v adrese k číslování svých zákazníků - místních
ISP nebo větších sítí, kterým poskytuje konektivitu (SLA, service level aggregator).
Identifikátorů nejvyšší úrovně TLA, tedy páteřních sítí a propojovacích bodů, může být až 8192
(2^13). Páteřní směrovače musí obsahovat alespoň jeden záznam ve směrovací tabulce pro každé
aktivní TLA. Dále budou jejich směrovací tabulky obsahovat další podrobnější záznamy pro tu TLA
oblast, ve které se nachází.
SLA slouží pro vytváření podsítí (až 65536-ti různých, pokud by byly v jedné úrovni) v místní
sítí lokality. Využití SLA má v moci ta organizace, která dostala přidělen prefix TLA+celé NLA (48
bitů). Stejně jako v případě NLA si může zvolit plochý adresní prostor, nebo sítě členit do více úrovní
podle potřeby. 16 bitů by mělo stačit i pro největší organizace – pokud by někdy bylo potřeba více,
mohou se domluvit se svým poskytovatelem o přidělení dalšího 48mi bitového TLA+NLA prefixu.
Přidělený TLA nebo krátký NLA prefix je možné dále členit téměř libovolným způsobem,
záleží na potřebě a záměrech konkrétního správce prefixu, jak s ním naloží. Ten může pevně přidělit
svým zákazníkům celý zbytek pole (delší prefix) nebo jen jeho začátek (kratší prefix) a delegovat tak
využití zbytku pole na ně (na poskytovatele nižší úrovně, kteří mohou poskytovat služby pro další subposkytovatele a tak dále). Není nutné striktně dodržovat třístupňovou strukturu poskytovatelů, může
jich být pod sebou k dané koncové síti méně nebo více (a pak půjde o menší pole NLA1, NLA2,
NLA3…, ze kterých se celé NLA bude skládat). Členění může vytvářet i jeden subjekt v rámci své
sítě, například může tvořit hierarchie podle států, krajů nebo měst – podle toho, jakou hierarchii
směrovačů ve své síti má. CESNET například dostal přidělen prefix délky /35 (TLA+NLA1).
Zbývající pole rozčlenil na NLA2, které je určeno pro města a NLA3, které je určeno pro koncové
instituce v těchto městech (viz. obrázek 12), což odpovídá jeho hierarchii přístupové sítě.
Je ale velmi doporučeno přidělovat koncovým sítím prefixy o standardní délce /48, aby tyto
mohly bez problémů využít 16 bitů pro tvorbu podsítí všude na světě a v případě nutnosti mohly celé
přejít k jinému /48 poskytovateli bez nutnosti změny struktury celé sítě. V členění polí TLA a NLA
ještě může dojít ke změnám.
03
I TLA
16
35 42 48
NLA1
N2 N3
64
SLA
128
ID rozhraní (EUI-64)
Obrázek 12: Možné další členění pole NLA
strana 60
Adresy tedy nejsou přidělovány bez ohledu na umístění sítě a připojovací bod k poskytovateli
jako v IPv4, ale mírně usměrněně tak, aby šly prefixy agregovat co nejlépe a s co nejmenší námahou.
Zákazník dostane adresy z velkého rozsahu svého poskytovatele, takže při agregaci všech zákazníků
připojených přes daného ISP se dají všechny jejich sítě sdružit na směrovači vyšší úrovně do jednoho
záznamu. Při členění prefixů je tedy dobré respektovat topologii své sítě (a například dále členit adresu
podle přístupových bodů v různých státech a městech), aby se výhody agregace projevily i v síti
poskytovatele (NLA) a zákazníka (SLA).
Základní ideou přidělování prefixů registračními institucemi je, že sítě, které budou připojovat
mnoho dalších sítí, dostanou přidělen krátký prefix, a ten budou svým zákazníkům na bezprostředně
nižší úrovni rozdělovat. A ti jej zase budou rozdělovat dále. Koncoví zákaznici pak nakonec dostanou
dlouhý (/48 až /64 bitů) prefix, ve kterém budou mít prostor už jen na členění své sítě.
Bylo tedy třeba najít vhodný mechanismus, komu jak dlouhé adresy přidělit (aby koncové a
malé sítě nedostaly zbytečně krátké prefixy a naopak páteřní poskytovatelé neměli málo prostoru na
členění a rozdělování adres svým zákazníkům). Pokud budou chtít menší ISP připojovat další sítě
(zvýšit počet hierarchických úrovní v připojovacím stromu), musí adresy rozdělovat opatrně, aby na ty
„pod nimi“ ještě zbyl nějaký manévrovací prostor při vytváření podsítí – agregátorům všech úrovní
dohromady je vyhrazeno pouze prvních 64 bitů adresy.
8.2.2. Přidělování v praxi
V současné době jsou zájemcům o adresní rozsahy přidělovány dva druhy záznamů:
- Testovací (vyhrazené pro zkušební účely sítě 6bone).
- Provozní (určené pro „ostré“ použití, pro poskytování IPv6 konektivity zákazníkům).
Testovací rozsah byl určen organizací IANA jako dočasné přidělení jednoho z 8192 dostupných
TLA prefixů k výzkumným účelům. Důvodem bylo ověření mechanismů registrace a přidělování
adres na různých úrovních internetových poskytovatelů v sítí 6bone. Byla vybrána poslední TLA
oblast s identifikátorem 0x1FFE, který společně s úvodní sekvencí bitů označující globální adresu
(001) dá dohromady prefix 3FFE::/16. Tyto adresy tedy nalezneme v síti 6bone a při jakémkoliv
zkoušení a testování IPv6 se s nimi setkáme velmi často. Část adres z tohoto rozsahu může získat de
facto kdokoliv, kdo projeví zájem o připojení a má potřebné technické vybavení.
Adresy v síti 6bone jsou dále členěny speciálním způsobem (jinak než v ostatních TLA).
Důvodem je možnost si vyzkoušet také přidělování všech různých druhů prefixů (TLA, NLA, SLA),
aniž by se dále zasahovalo do adresního prostoru IPv6 mimo síť 6bone. Jsou tedy definována pole
pseudo-TLA (pTLA, 12 bitů) a pseudo-NLA (pNLA, 20 bitů), která jsou v místě běžného 32 bitového
NLA popsaného výše. pTLA tedy tvoří páteřní strukturu sítě 6bone podobným způsobem, jako TLA
tvoří (resp. budou tvořit) páteř a nejvyšší úroveň agregace celé globální IPv6 sítě. Jde o jakousi
zkušební „síť v síti“.
Všechny ostatní TLA prefixy jsou určeny pro ostré provozní použití a budou registrovány až
vážným zájemcům o poskytování konektivity na pravidelné bázi (podmínky jsou uvedeny dále).
Speciálním případem provozního TLA prefixu je prostor číslo 1 (prefix 2001::/16), který je opět
členěn jiným způsobem než ostatní. Existuje v něm totiž pole SubTLA o velikosti 13 bitů (má stejnou
velikost jako TLA a existuje hned za ním na úkor pole NLA), jehož účelem je ověřovat potřebnost
přidělení adres pro velké poskytovatele – s jeho pomocí je možné určit, zda žadatel o velký rozsah
adres jej skutečně potřebuje. Jak to funguje?
Pro přidělení optimálního počtu adres sítím poskytovatelů a institucím byl navržen následující
mechanismus. Páteřním poskytovatelé (nad kterými už poskytovatel vyšší úrovně není), a tedy
potenciální žadatelé o nejkratší prefixy TLA (/16), budou muset splnit následující velmi striktní
podmínky přidělování:
- Nutnost poskytování tranzitních přenosových služeb, nejlépe páteřních.
- Fungující nativní (ne tunelovaný) IPv6 provoz nebo podrobné plány na jeho spuštění do tří
měsíců.
- Periodické poskytování statistik o využití svého adresního prostoru.
- Placení registračního poplatku organizaci IANA.
- Poskytování registračních služeb pro poskytovatele nižší úrovně a zveřejňování jejich seznamu.
- Provozní využívání přiděleného prostoru
strana 61
Poté získá žadatel pro své potřeby od registrační instituce (RIPE NCC, ARIN, APNIC) dočasný
SubTLA prefix o délce /29 právě v prostoru 2001::/16 a v jeho rámci začne rozdělovat zbývající
zkrácené NLA ID svým zákazníkům (nejčastěji dalším ISP). Pokud doloží, že vyčerpal již 90 procent
tohoto adresního prostoru, bude mu žádost o samostatné TLA uznána a identifikátor mu bude přidělen.
Pokud podmínku 90 procent nesplní, TLA nedostane, a pokud přestane v průběhu ověřování splňovat i
základní předpoklady (tranzitní charakter apod.), přijde i o přidělený SubTLA /29 prefix. Důležitou
skutečností také je, že přidělení nějakého prefixu od registrační instituce neznamená jeho vlastnictví,
ale spíše jeho správu a delegaci odpovědnosti za jeho další rozdělování.
Původní rozdělení rozsahu SubTLA identifikátorů je následující (obsaženy jsou pouze
registrační instituce Internetu):
Binární hodnota
0000 000X XXXX
0000 001X XXXX
0000 010X XXXX
0000 011X XXXX
0000 100X XXXX
0000 101X XXXX
0000 110X XXXX
0000 111X XXXX
0001 000X XXXX
.
.
.
.
.
.
.
.
.
1111 111X XXXX
X
X
X
X
X
X
X
X
X
Rozsah prefixů
2001:0000::/29 2001:0200::/29 2001:0400::/29 2001:0600::/29 2001:0800::/29 2001:0A00::/29 2001:0C00::/29 2001:0E00::/29 2001:1000::/29 -
X
2001:FE00::/29 - 2001:FFF8::/29
2001:01F8::/29
2001:03F8::/29
2001:05F8::/29
2001:07F8::/29
2001:09F8::/29
2001:0BF8::/29
2001:0DF8::/29
2001:0FF8::/29
2001:11F8::/29
Přiřazení Zkráceně
IANA
2001:00-01/23
APNIC
2001:02-03/23
ARIN
2001:04-05/23
RIPE NCC 2001:06-07/23
(zatím nepřiřazeno)
Blok adres rezervovaný organizaci IANA je určen pro experimentální provoz a testování
nových přístupů, například při agregování směrování podle propojovacích bodů.
Poskytovatelům dále od páteře Internetu a tranzitním výměnným bodům mohou být přidělovány
delší prefixy. Přístupovým ISP by měly být přidělovány od vyšší úrovně poskytovatelů adresní
rozsahy o délce /35, které by pro ně měly vytvořit dostatek prostoru pro hierarchizaci přístupové sítě
k zákazníkům. Prefix této délky je možné získat i v TLA prostoru 1 od některé z registračních institucí
(nezávisle na poskytovateli vyšší úrovně) po splnění stanovených podmínek (příklad podmínek RIPE
NCC):
- Musí existovat plná BGP konektivita (peering) alespoň do dalších tří sítí.
- Musí existovat plány na start rutinního poskytování konektivity zákazníkům do 12 měsíců od
přidělení prefixu
- Zájemce musí doložit své vybavení IPv6 technikou a plán dalšího rozvoje
- Zájemce musí mít minimálně půlroční zkušenosti s aktivní účastí v síti 6bone (jako pTLA) nebo
alespoň 40 potenciálních zájemců (zákazníků) o prefix s délkou /48
- Zájemce musí být členem RIPE NCC jako lokální registrátor (LIR).
Získání provozního prefixu /35 přímo pro internetového poskytovatele od registrační instituce
tedy není úplně snadné a v České republice jej má přidělen pouze akademická síť CESNET. Ostatní
čeští komerční poskytovatelé internetového připojení o přidělení tohoto prefixu dle svých slov usilují.
Koncovým sítím by měly být přidělovány přímo od přístupových ISP /48 prefixy, protože se
předpokládá, že ty už konektivitu nebudou poskytovat dalším subjektům a na tvorbu podsítí bude 16
SLA bitů stačit. Délka SLA už by se neměla v budoucích změnách významu jednotlivých částí adresy
měnit, hranice /48 se zdá být pevným bodem pro rozlišení veřejné infrastruktury Internetu a sítě
koncové instituce.
Dalším v současném IPv6 Internetu používaným rozsahem adres je prefix 2002::/16 (TLA
prostor číslo 2), kde však také registrace neprobíhá běžným způsobem, ale prefixu jsou přidělovány
mechanismem popsaným v kapitole o přechodové technologii 6to4.
strana 62
8.3.
Stav registrace pro VŠE
VŠE neměla na začátku dubna 2002 zaregistrován žádný oficiální ani testovací rozsah IPv6
adres. Pro připojení do celosvětové sítě je nezbytné nějaký oficiálně přidělený prefix mít, minimálně
pro adresování přístupového spoje (koncového rozhraní tunelu).
Příležitostí k registraci části adres pro použití VŠE je několik. Řada poskytovatelů tunelovacích
služeb zdarma nabízí ke svému tunelu i registraci adresního prostoru určité délky, který si pak daná
připojená síť může rozdělit podle vlastních potřeb. Adresy tímto způsobem přidělované jsou z balíku
testovací sítě 6bone (3FFE::/16).
Jinou možností je pokusit se splnit podmínky některé z provozních registračních organizací
(RIPE NCC, ARIN, APNIC) a získat přímo pro sebe velký /35 rozsah. Tuto variantu nepokládám za
reálnou, protože VŠE není a budoucnu zřejmě ani nebude poskytovatelem internetového připojení pro
další instituce.
Další možností je kontaktovat poskytovatele připojení školy, kterým je sdružení CESNET, a
požádat jej o přidělení adres v rozsahu, který běžně přiděluje svým zákazníkům. Tato varianta je asi
nejlepší jak z hlediska administrativní správnosti a odpovídající velikosti prefixu, tak i pro budoucí
použití, protože neočekávám výraznější změny v oblasti připojení VŠE do Internetu. Z CESNETu je
možné dostat přiděleny dva druhy prefixů – jak zkušební sítě 6bone, tak i provozní od organizace
RIPE NCC (ten je v ČR přidělen zatím právě pouze CESNETu, viz. výše).
Pro účely testování připojení do IPv6 Internetu, popsaného v následující kapitole diplomové
práce, jsem využil první možnost a požádal o adresní rozsah poskytovatele Freenet6. Tato operace je
administrativně poměrně jednoduchá, stačí se registrovat přes webový formulář na serveru Freenet6,
k níž je potřeba pouze fungující e-mailová adresa a zvolené uživatelské jméno. Registrovat a požádat o
adresní rozsah tedy může téměř kdokoliv.
Po zpětném potvrzení registrace po chvíli se lze s přiděleným uživatelským jménem a heslem
k tunelovacímu serveru připojit. Zájemci o přidělení prefixu ještě musí upravit konfigurační soubor
(podrobněji je postup popsán v následující kapitole) a tunelovací démon pak připojenému systému
sdělí hodnotu přiděleného prefixu. Ten jsem získal v očekávané délce 48 bitů, takže pro adresaci
vnitřních podsítí mi zbylo plně postačujících 16 bitů.
Prefix je tedy registrován na mou e-mailovou adresu, nicméně sloužil ke školním účelům na
hardware patřícímu VŠE, takže jej neoficiálně mohu považovat za adresní rozsah přidělený VŠE.
Směrování do testovací sítě na základě tohoto prefixu probíhalo po celou dobu testování bez
problémů. Registraci prefixu potvrzuje následující výstup tunelovacího programu:
Process response from server
TSP_PREFIX
TSP_PREFIXLEN
3ffe:0b80:0b74
48
Router configuration
Kernel setup
add net 3ffe:0b80:0b74::: gateway lo0
net.inet6.ip6.forwarding: 1 -> 1
net.inet6.ip6.accept_rtadv: 0 -> 0
Adding prefix 3ffe:0b80:0b74:: to ep0
Do budoucna bude nutné získat odpovídající část adresního prostoru od CESNETu, a to jak pro
zkušební, tak pro ostré provozní využití. Přidělení by bylo vhodné co nejdříve, aby se odstranila
nutnost pozdějšího několikanásobného přečíslování sítě VŠE podle aktuálně přiděleného prefixu a
vytvořilo se stabilní prostředí pro provádění dalších testů. Tuto operaci by bylo možné provést
současně s předpokládaným vytvořením připojení (tunelu) do IPv6 sítě CESNET. Obě akce nejsou
administrativně ani technicky příliš složité, nicméně zatím jim brání neexistence stálého IPv6 uzlu na
VŠE. Po zřízení pevné testovací IPv6 sítě bude možné získat konektivitu i adresní rozsah v rámci
zapojení VŠE do řešení výzkumného projektu sítě IPv6.
strana 63
9. Zkouška implementace a připojení do Internetu v malé síti
9.1.
O této kapitole
V této části diplomové práce shrnuji poznatky získané při stavbě a provozu malé zkušební sítě,
které jsem při praktických zkouškách implementací IPv6 v různých operačních systémech získal.
Kapitola obsahuje popis topologie sítě, nastavení tunelů a použité operační systémy jednotlivých uzlů.
Její součástí jsou také výsledky použitelnosti jednotlivých platforem (podporovaných a stabilních
vlastností) a aplikací. Podrobnější konfigurační informace jsou v příloze práce.
9.2.
Výchozí situace
9.2.1. Cíle zkušební sítě
Cílem testování zařízení a programů ve zkušební síti je ověření funkčnosti a principů IPv6
v praxi. Mým záměrem bylo v návaznosti na [42] ověřit následující:
- podporu IPv6 na síťových rozhraních v operačních systémech
- připojení tunelem a přenos dat po něm
- rozdělování přiděleného globálního prefixu do dalších podsítí
- směrování mezi těmito sítěmi – statické a dynamické (RIPng)
- automatická konfigurace uzlů sítě (bezstavová), použití spojově místních adres
- funkčnost a použitelnost aplikačních služeb (interně v rámci zkušební sítě, ale i externě):
• http server, http prohlížeč (webové služby)
• ftp server, ftp klient (přenos souborů)
• ssh server, ssh klient (zabezpečený vzdálený přístup)
• smtp server (elektronická pošta)
• různé síťové nástroje
- chování při výpadku některého ze spojů
- nasazení některého z automatických tunelovacích mechanismů
- spolupráci s existující IPv4 infrastrukturou na bázi DNS a SMTP (překladové brány)
9.2.2. Popis zkušební sítě
Zkušební síť pro účely této práce jsem vytvořil se svolením oddělení síťové infrastruktury VC
VŠE přímo v síti VŠE v lokalitě Žižkov. Využil jsem již existující IPv4 infrastruktury a v dočasně
nepoužívané části sítě jsem vytvořil a upravil některé spoje tak, aby mohla být vytvořena zkušební síť
bez ovlivnění běžného provozu školy. Použitá výpočetní technika patří VŠE, software je buď pro VŠE
licencován (Solaris 8) nebo je volně dostupný (FreeBSD, KAME, Mozilla aj.).
Laboratorní síť obsahuje tři uzly, každý se dvěma síťovými rozhraními. Jde o počítače:
- BSD je počítač PC Intel Pentium 133 s operačním systémem FreeBSD 4.5. U tohoto počítače
vzhledem ke stavu implementací počítám s nejlepší funkčností a proto jsem se jej rozhodl
používat jako hlavní uzel a přístupový směrovač (rozesílá po síti ohlášení směrovače). Zde je
ukončen externí tunel po IPv4 infrastruktuře
- ASTRA je počítač Sun Ultra 2 s operačním systémem Solaris 8 obsahujícím menší podporu IPv6.
Je použit jako koncový uzel, případně může vykonávat i základní směrovací funkce (RIPng) a po
přenesení některých programů může být i aplikační server. Při konfiguraci jsem využíval [36,37].
- STROM je počítač Sun Netra X1 s operačním systémem Solaris 8. Využití uzlu je podobné jako u
ASTRY, tedy jako místa pro testování spojení a uživatelských aplikací pro systémy typu Unix.
Všechny uzly mají implementován dvojí protokol (verze 4 i 6), jednu z verzí ale lze libovolně
potlačit. Podpora obou protokolů mi umožnila vynechat při implementaci speciálně vyhrazenou
překladovou bránu, zejména pro DNS a SMTP služby, která by v případě IPv6-only uzlů byla nutnou
součástí takové testovací sítě. V současné situaci je překlad pro tyto služby prováděn přímo na
zmíněných dvouprotokolových uzlech na aplikační úrovni.
Topologie sítě má trojúhelníkový tvar – každé zařízení je v základní konfiguraci propojeno
s oběma ostatními (full mesh). Zvolil jsem ji proto, že jde o rozvržení, na kterém lze zkoušet širokou
škálu různých konfigurací propojení, tunelování a spolupráce uzlů. Přímé propojení je na základě
nativních IPv6 linek (nad Ethernetem),v některých částech sítě koexistuje protokol IPv6 s IPv4 na
strana 64
jednom sdíleném spoji. Při testování jsem v topologii sítě prováděl některé změny (například
nahrazení nativního spoje tunelem po IPv4 infrastruktuře nebo přerušení některého spoje zcela). Úplný
výpis připojených síťových rozhraní a směrovacích tabulek na každém uzlu je uveden v příloze práce.
IPv4 směrovač VŠE
146.102.76.0/21
Freenet 6
146.102.32.0/20
přepínač
přepínač
rozbočovač
ip.tun0
gif0
hme0
ASTRA
dmfe1
BSD
STROM
lnc0
146.102.77.88
ip.tun0
ep0
dmfe0
146.102.76.27
146.102.39.39
Vysvětlivky:
Tunelovaný IPv6 spoj přes IPv4 infrastrukturu
Provoz pouze IPv4 paketů po Ethernetu
Provoz pouze IPv6 paketů po Ethernetu
Společný provoz IPv4 a IPv6 paketů po Ethernetu vedle sebe
hme0
146.102.76.27
Název síťového rozhraní v operačním systému
Adresa příslušná k IPv4 rozhraní, případně prefix podsítě
Obrázek 13: Fyzické schéma testovací IPv6 sítě
strana 65
3ffe:b80:2:7df9::/128
BSD
Freenet 6
gif0
ep0
lnc0
::2a0:24ff:fe3d:aa76 ::2c0:6cff:fe79:9153
3ffe:b80:b74:1::/64
::a00:20ff:fe88:f8b7
hme0
3ffe:b80:b74:2::/64
::203:baff:fe05:214a
dmfe0
ASTRA
STROM
ip.tun0
ip.tun0
3ffe:b80:b74:3::/128
Vysvětlivky:
Tunelovaný IPv6 spoj přes IPv4 infrastrukturu
::a00:20ff:fe88:f8b7
3ffe:b80:b74:1::/64
hme0
Nativní IPv6 spoj
EUI-64 identifikátor rozhraní
Prefix podsítě
Název síťového rozhraní v operačním systému
Obrázek 14: Logické schéma testovací IPv6 sítě
9.2.3. Tvorba zkušební sítě
Prvním krokem při sestavování zkušební sítě je instalace operačního systému na všechny uzly.
Jde o relativně snadnou záležitost (jak FreeBSD 4.5, tak i Solaris 8 disponují poměrně sofistikovaným
průvodcem instalace), takže ji zde nebudu popisovat. Při jejím provádění je vhodné nastavit IPv6
podporu na zapnutou, nicméně to se dá provést i ručně editací konfiguračních souborů později. Oba
systémy již mají podporu IPv6 v nějakém stavu integrovánu, takže nebylo potřeba provádět systémové
úpravy nízké úrovně (kompilace jádra a podobně).
Nejdříve jsem počítač BSD nastavil pro připojení do IPv6 sítě samostatně. Počítač má dvě
fyzická síťová rozhraní (Ethernetové karty), ep0 a lnc0. V první fázi jsem nastavil rozhraní ep0
běžným způsobem pro použití IPv4 protokolu (IPv4 adresa, maska a výchozí brána, konfiguraci
neuvádím). Přes toto rozhraní jsem vytvořil virtuální rozhraní gif0, což je koncový bod tunelu pro
spojení do IPv6 sítě Použil jsem veřejně dostupný tunelovací server Freenet6, kde jsem získal
zdrojové kódy tunelovacího démona tspc, kterého jsem do binární podoby přeložil příkazem
# make all target=FreeBSD4.5 installdir=/usr/local/freenet
A spuštění tunelu neboli vytvoření dalšího rozhraní gif0 jsem provedl příkazem
# /usr/local/freenet/tspc -vf /usr/local/freenet /tspc.conf
Podrobný výpis programu mě informoval o načítaných konfiguračních volbách načítaných
z konfiguračního souboru tspc.conf (viz dále). Program na závěr vytvořil (angl. „plumb“) nové
rozhraní a do směrovací tabulky přidal implicitní výchozí cestu. Tím jsem se úspěšně připojil do sítě
Freenet6. Konektivitu jsem ověřil nástroji ping6 a traceroute6:
# traceroute6 www.kame.net
traceroute6 to kame220.kame.net (3ffe:501:4819:2000:210:f3ff:fe03:4d0) from
3ffe:b80:2:7df9::2, 30 hops max, 12 byte packets
1 3ffe:b80:2:7df9::1 119.682 ms 118.518 ms 118.586 ms
strana 66
2
3
4
5
6
7
8
9
10
viagenie-tnet.gw.ipv6.asterix.hu 109.519 ms 113.111 ms 109.781 ms
3ffe:8000:ffff:b::1 450.233 ms 475.465 ms *
2001:200:0:1802:2a0:ccff:fe73:4413 663.105 ms 800.137 ms 689.175 ms
pc6.otemachi.wide.ad.jp 760.071 ms 670.485 ms 726.223 ms
pc1.notemachi.wide.ad.jp 673.02 ms 698.541 ms 759.661 ms
pc3.yagami.wide.ad.jp 733.119 ms 778.474 ms 728.174 ms
2001:200:1b0:1000::2000:1 746.737 ms 750.104 ms 727.407 ms
paradise.kame.net 748.243 ms 702.804 ms 779.777 ms
apple.kame.net 673.234 ms 697.104 ms 679.492 ms
V další fázi jsem si od instituce Freenet6 vyžádal vlastní /48 prefix, který jsem měl v úmyslu
použít pro adresaci síťových rozhraní ve vnitřní síti v jednoduchých podsítích o délce prefixu 64 bitů.
Tato operace se provede vložením několika řádek do konfiguračního souboru tspc.conf:
host_type=router
prefixlen=48
if_prefix=ep0
Tunelovacímu programu se jimi sdělí, že náš uzel není koncový, ale je přístupovým
směrovačem pro další počítače a že vnitřní síť se bude nacházet za rozhraním ep0 (zatím není pro IPv6
nakonfigurováno). Tím, že se z počítače BSD stal směrovač, se na něm automaticky spustil démon
rtadvd, který zabezpečuje na všech rozhraních rozesílání ohlašování směrovače (Router Advertising).
Jde o mechanismus automatické konfigurace - ohlašování směrovače pro koncové připojené uzly na
jednotlivých rozhraních tak, aby mohly bez použití DHCP serveru (bezstavově) sestavit svou globální
adresu, získat délku prefixu sítě a podobně (viz podkapitola v teoretické části). Mnou získaný síťový
prefix je
3ffe:0b80:0b74::/48
Jde tedy o testovací rozsah sítě 6bone.
V druhé fázi testování jsem připojil do sítě druhý zkušební počítač ASTRA s operačním
systémem Solaris 8. Fyzicky byl tento stroj připojen na stejný rozbočovač (tedy do stejné IPv4
podsítě) jako BSD a opět byl zkonfigurován běžným způsobem pro IPv4 (rozhraní hme0). Provoz na
tomto rozbočovači byl probíhal jak pro protokoly IPv4, tak IPv6, nicméně spojení mezi BSD a
ASTRou bylo nativní, netunelované – šlo o nezávislý provoz dvou protokolů na stejné infrastruktuře
bez dalších vazeb.
Pro propojení na bázi IPv6 s počítačem BSD jsem na obou počítačích na odpovídajícím
rozhraní (ep0 a hme0) nastavil podporu IPv6 adres. Nejdříve jsem nechal konat automatické
mechanismy – démon tspc při získání prefixu automaticky na vnitřním rozhraní ep0 nastavil adresu
dle vzoru přidělený prefix (48 bitů) +adresa sítě (16 bitů) + adresa rozhraní (64 bitů) na hodnotu
3ffe:b80:b74:1::1/64
Adresa první sítě je tedy 1, adresa rozhraní směrovače v této síti (BSD) je 1.
Na počítači ASTRA stačí pro spuštění mechanismu automatické konfigurace po rebootu
zařízení vytvořit prázdný soubor /etc/hostname6.rozhraní, v mém případě tedy
/etc/hostname6.hme0. Inicializace rozhraní proběhla v pořádku a z ohlášení směrovače BSD si
rozhraní nastavilo adresu
3ffe:b80:b74:1:a00:20ff:fe88:f8b7/64
Prvních 64 bitů získal počítač jako prefix sítě od směrovače a posledních 64 bitů si sestavil sám
jako EUI-64 z MAC adresy rozhraní. Současně si ASTRA upravila svou směrovací tabulku tak, aby
implicitní cesta byla nastavena přes směrovač BSD.
Třetím krokem tvorby sítě bylo připojení posledního testovacího uzlu STROM, taktéž
s operačním systémem Solaris 8, k výstupnímu směrovači BSD. STROM má dvě fyzická síťová
rozhraní, dmfe0 a dmfe1. Na rozhraní dmfe1 je nakonfigurován běžný IPv4 přístup. Využil jsem
volných rozhraní na obou počítačích a propojil přes strukturovanou kabeláž budovy (servery se
nacházely každý v jiné lokalitě) oba uzly kříženým kabelem přímo (rozhraní lnc0 a dmfe0). Vznikl
strana 67
tedy vyhrazený, IPv6 nativní spoj nad Ethernetem. Pro konfiguraci adresy na rozhraní směrovače BSD
jsem musel upravit konfigurační soubor démona rtadvd, tak, aby rozhraní lnc0 přiřadil adresu
3ffe:b80:b74:2::1/64
Adresa je tedy velmi podobné té na prvním rozhraní, ale protože jde o jinou síť, má také vyšší
číslo (2) než ta přístupná přes rozhraní ep0. Na počítači STROM se díky analogickému nastavení jako
na počítači ASTRA provedla úspěšně automatická konfigurace a rozhraní se přiřadila adresa
3ffe:b80:b74:2:203:baff:fe05:214a/64
Základní kostra zkušební sítě tedy byla hotova. Ze všech uzlů jsem ověřil konektivtu pomocí
ICMP nástrojů (ping a traceroute) na ostatní uzly sítě a do vnějšího IPv6 Internetu (www.kame.net,
některé tunely CESNETu a podobně).
9.3.
Průběh a výsledky testování
9.3.1. Jmenné služby (DNS)
Dalším důležitým krokem, zejména pro zjednodušení administrativní práce s adresami, bylo
zprovoznění DNS služeb pro IPv6 adresy. Pro správné fungování překladu jmenných a číselných adres
je nutné také vytvoření reverzních záznamů a domény IP6.ARPA v DNS. V ní se budou reverzní
dotazy zpracovávat postupem naznačeným v teoretické části. Původně se tato doména nazývala
IP6.INT (a tak jsem ji také testoval), podle nové dohody je v současnosti preferovaným tvarem už
IP6.ARPA a starý tvar by se již neměl používat.
Varianty zřízení jmenného serveru byly v zásadě dvě. První z nich byla instalace a konfigurace
vyhrazeného DNS serveru přímo na počítači BSD, který by obsahoval pouze záznamy pro zkušební
síť a veškeré ostatní dotazy (na počítače s IPv4 a počítače s IPv6 mimo VŠE) by řešil dotazem
nadřízenému serveru (tedy nejspíše primárnímu serveru školy). Použitým software by mohl být
program BIND od verze devět a výše (podporuje už dotazy po IPv6 rozhraních). Druhá varianta
znamenala integraci IPv6 záznamů přímo do primárního DNS školy, který funguje v rámci IPv4
infrastruktury. Dotazy na něj by musely uzly zvládnout v IPv4, použitým software by musel být BIND
od verze 8.2 a výše (podporuje AAAA záznamy, ale neumí využít IPv6 k jejich přenosu).
Vzhledem k dvouprotokolovému charakteru všech testovacích počítačů jsem se rozhodl využít
primárního DNS serveru vse470.vse.cz, který slouží výhradně na IPv4 infrastruktuře. Je na něm
díky péči outsourcingové firmy ICZ, a.s. nainstalován program BIND ve verzi 9, takže DNS
podporuje všechny nejnovější prvky protokolu IPv6. Rizikem této varianty by mohlo být narušení
funkčnosti pro IPv4 uzly mimo testovací síť, čemuž jsem se chtěl vyhnout. Přínosem by pak mohla být
úzká integrace, odpadnutí potřeby instalovat dedikovaný server a přiblížení se co nejvíce budoucímu
stavu, kdy budou oba druhy záznamů na společném serveru. Další výhodou mnou zvoleného řešení je,
že bych zároveň otestoval stávající provozní systém na kompatibilitu s IPv6 a zjistil záležitosti, které
by pak při budoucím přechodu celé sítě VŠE bylo nutno upravit.
Z hlediska koncových uzlů byl počítač BSD schopen používat DNS bez jakýchkoli úprav.
V operačním systému Solaris je potřeba pro korektní chování upravit v souboru /etc/nsswitch.conf
řádek, který začíná slovem „ipnodes“, takto:
ipnodes
files dns
Znamená to, že IPv6 adresy se mají vyhledávat jak lokálně v souboru /etc/inet/ipnodes
(který je IPv6 analogií souboru /etc/hosts pro IPv4), tak i pomocí DNS serverů. Ve standardní
instalaci bývá nastaveno pouze lokální vyhledávání. V případě problémů s DNS je možné editovat
právě soubor /etc/inet/ipnodes, nicméně se vzhledem ke komplikovanosti zápisu adres
nedoporučuje zde uvádět napevno jiné než nezbytně nutné adresy.
Z důvodu jednoduchosti jsem pro označování jmen uzlů v DNS použil jen AAAA záznamy (ne
A6). Adresy pro nový protokol jsem do celoškolské databáze zavedl stejným mechanismem, který je
na VŠE použit pro IPv4 adresy, tedy editací základního MASTER souboru [5]. Ten je pak skripty, které
nejsou součástí BINDu, upraven do více zónových souborů různých tvarů pro BIND potřebných (např.
strana 68
automaticky se vytvoří reverzní doména). Protože skripty z pochopitelných důvodů nepodporují IPv6,
musel jsem tvar záznamů upravit tak, aby se záznamy vytvářely správně. Namísto zápisu tvaru
hostname.ipv6
AAAA
1234:feca::5678:efgh
je tak vhodnější použít
hostname.ipv6
IN
AAAA
1234:feca::5678:efgh
Po aktualizaci DNS databáze začal úspěšně fungovat překlad jmen na číselné adresy. Aby
fungoval také opačný překlad, je nutno ručně vytvořit reverzní doménu s PTR záznamy. To jsem
provedl podle způsobu naznačeného v kapitole o DNS v teoretické části. Aby jmenný server
(„nameserver“) novou reverzní doménu zavedl, je třeba přidat do konfiguračního souboru
/etc/named.conf další odkaz zónový soubor s PTR záznamy. Celý výpis konfiguračních souborů je
uveden v příloze diplomové práce (zápis by se dal ještě zjednodušit pomocí prefixových zkratek).
Takto funguje obousměrný překlad správně v rámci sítě VŠE a jednosměrný překlad (ze jmen
na čísla) v celém zbývajícím IPv6 Internetu. Pro účely testování je to dostačující, nicméně může
vzniknout požadavek na dostupnost obousměrného překladu i ze sítí mimo VŠE (pro ostrý provoz to
bude nezbytné). Aby fungoval, je třeba požádat o delegaci reverzní DNS domény ten subjekt, od
kterého má síť VŠE přidělen rozsah adres (sdělit síti Freenet6, že naše síť je správcem jmen právě pro
tuto část jeho velkého prefixu). Freenet6 je analogickým způsobem delegován svým přípojným
partnerem vyšší úrovně, od kterého dostal velký rozsah adres a takto se dá dojít až do kořenových
jmenných serverů pro doménu IP6.ARPA.
V případě sítě Freenet6 se žádost o reverzní delegaci ze strany poskytovatele zařídí řádkou
v konfiguračním souboru
dns_server=vse470.vse.cz
Zmíněný server musí být nejdříve nakonfigurován lokálně, že se s danou reverzní doménou umí
vypořádat. Tuto podmínku jsem splnil a funkčnost delegace reverzní domény jsem experimentálně
ověřil přes webovou traceroute bránu ze sítě stben.be, kde jsem zadal hledání cesty na stroj BSD,
jehož adresu jsem zadal číselně. Po vyhledání cesty byl schopen cizí uzel v Belgii získat podle číselné
adresy i správnou jmennou.
# lynx http://www.stben.be/cgi-bin/route6?address=strom3.ipv6.vse.cz
traceroute from www.stben.be to strom3.ipv6.vse.cz
traceroute to strom3.ipv6.vse.cz (3ffe:b80:b74:3:203:baff:fe05:214a) from
3ffe:80b0:100:1:250:4ff:fe37:5976, 30 hops max, 16 byte packets
1 rout-dom.stben.be (3ffe:80b0:100:1:201:2ff:fef7:139b) 0.177 ms 0.111 ms
2 STBEN-BE.ipv6.viagenie.qc.ca (3ffe:b00:c18::68) 158.551 ms 143.833 ms
3 3ffe:b80:2:4719::1 (3ffe:b80:2:4719::1) 151.961 ms 151.964 ms
4 VSE-TEST.tsps1.freenet6.net (3ffe:b80:2:7df9::2) 255.959 ms 255.948 ms
5 astra.ipv6.vse.cz (3ffe:b80:b74:1:a00:20ff:fe88:f8b7) 255.966 ms 255.961 ms
6 strom3.ipv6.vse.cz (3ffe:b80:b74:3:203:baff:fe05:214a) 319.943 ms 263.961 ms
Funkčnost DNS systému pro IPv6 byla úspěšně vyzkoušena na stejné úrovni jako pro IPv4.
Síťová vrstva pro pokládání DNS dotazů byla IPv4, protože nebyl instalován dedikovaný IPv6 jmenný
server, ale využit stávající, který má pouze IPv4 rozhraní. Pro budoucí rutinní použití a editaci
seznamu adres by bylo vhodné upravit sestavovací skripty na serveru vse470.vse.cz, nastavit
používání prefixů, aby se adresy nemusely psát dlouhé a případně uvažovat o použití A6 záznamů. I
přes tyto úpravy bude údržba DNS náročnější než v IPv4, zvlášť pokud se VŠE rozhodne přidělovat
adresy uzlům podle EUI-64 a ne sekvenčně od nuly. V takovém případě by bylo vhodné použít mě
zatím neznámé mechanismy aktualizace DNS podle databáze síťových karet, případně jiné.
Jmenný server by v budoucnu mohl mít jedno z rozhraní i do IPv6 sítě, což by usnadnilo
zejména spolupráci s poštovním systémem (správné odpovědi na MX záznamy podle verze protokolu
dotazu, viz dále) a umožnilo existenci uzlů, které budou mít implementován pouze protokol IPv6.
Toto rozhraní by vedle své běžné adresy mohlo mít některou ze speciálně vyhrazených adres pro DNS
server, případně o sobě rozšiřovat informace po síti tak, aby se usnadnila automatická konfigurace
koncových uzlů. Nalezení dostupných DNS je totiž zatím nejslabším článkem bezstavové konfigurace,
strana 69
vyhledávání jmenných služeb v síti zatím není upraveno žádným standardem RFC, jen pracovním
dokumentem.
9.3.2. Tunelovací mechanismy
Mým dalším cílem bylo vyzkoušet fungování různých tunelovacích mechanismů mezi uzly
testovací sítě navzájem. Jde o vytvoření virtuálního síťového rozhraní, jehož druhý konec je na jiném
IPv6 uzlu a pakety jsou přenášeny po IPv4 síti. Pro zkoušení jsem zvolil počítače ASTRA a STROM,
které zatím nemají přímé propojení mezi sebou, pouze prostřednictvím uzlu BSD. Operační systém
Solaris umožňuje vytvoření automatického a manuálního tunelu. Oba se dají vytvořit při startu
počítače nebo až při jeho chodu. Systém BSD má automatický tunel nakonfigurován bez nutnosti
zásahu administrátora.
Automatický tunel je IPv6 rozhraní, kde se přijímají IPv6 pakety, které jiný uzel tuneluje přes
IPv4 (pošle v IPv4 hlavičce) na adresu ::v4_adresa_rozhraní. Prefix této sítě je tedy napevno ::/96,
nedá se mu přiřadit jiný. Charakter automatického tunelu je vícebodový. Pro jeho vytvoření se
v Solarisu se při startu systému se prohledávají soubory /etc/hostname6.ip.atunX kde X je
libovolné číslo sloužící pro odlišení více tunelů, pokud jsou nakonfigurovány (běžné je číslovat od
nuly). U automatického tunelu stačí nakonfigurovat začátek (vlastní IPv4 adresu a tutéž
transformovanou do IPv6 tvaru). Obsahem souboru pro konfiguraci je řádek
tsrc <IPv4-adresa> ::<IPv4-adresa>/96 up
Tunel lze spustit i ručně z příkazové řádky (příklad počítače ASTRA):
# ifconfig ip.atun0 inet6 plumb
# ifconfig ip.atun0 inet6 tsrc 146.102.77.88 ::146.102.77.88/96 up
Manuální tunel je klasický dvoubodový spoj, kde se na obou počítačích nastaví adresy začátku a
konce tunelu a pokud jsou správné, pakety se tunelují po IPv4 pouze mezi těmito dvěma rozhraními.
Konfigurační soubor pro Solaris se jmenuje /etc/hostname6.ip.tunX a obsahuje následující řádky:
tsrc <my-ipv4-address> tdst <peer-ipv4-address> up
addif <my-v6-address> <peer-v6-address> up
Na prvním řádku je nastavena zdrojová a cílová adresa v IPv4 síti a na druhém řádku je jejich
IPv6 ekvivalent. Prefix /128 je použit vzhledem k dvoubodovému charakteru spoje. Manuální tunel se
dá sestavit i z příkazové řádky (příklad počítače ASTRA s tunelem na počítač STROM):
# ifconfig ip.tun0 inet6 plumb tsrc 146.102.77.88 tdst 146.102.39.39 up
# ifconfig ip.tun0 inet6 addif 3ffe:b80:b74:3:a00:20ff:fe88:f8b7/128
3ffe:b80:b74:3:203:baff:fe05:214a up
IPv6 adresy jsem sestavil ručně z přiděleného prefixu sítě délky 48 bitů, mnou stanovené adresy
podsítě (3) délky 16 bitů a EUI-64 identifikátoru vygenerovaného z MAC adresy.
Automatické i manuální tunelové rozhraní jsem vytvořil na obou počítačích s OS Solaris a
úspěšně vyzkoušel nástrojem ping6. Pro testování lze použít i standardní multicastovou adresu
FF02::1 například takto:
# ping -s -i ip.tun0 ff02::1
Odpovědí by měly být odezvy od všech počítačů, které jsou připojeny k síti daného rozhraní.
Tunely lze vytvořit vcelku bez větších problémů, rychle a podle potřeby téměř kamkoliv.
Uplatnění by v rámci sítě VŠE mohly najít zejména při připojování geograficky oddělených uzlů nebo
sítí k centrálnímu IPv6 ostrovu s externí linkou, při vytváření virtuálních spojů při výpadku IPv6
infrastruktury, pro propojování více uzlů přes IPv4 bez nutnosti mezi každým z nich konfigurovat
dvoubodové spojení (u automatických tunelů) a podobně.
9.3.3. Směrování
Vytvořením virtuálního spoje mezi uzly ASTRA a STROM jsem získal trojúhelníkovou
topologii logické IPv6 sítě. Tu jsem se rozhodl využít pro vyzkoušení dynamického směrování v IPv6.
strana 70
Změnil jsem pojetí zkušební sítě jako směrovače s dvou uzlů ve dvou různých sítích na tři směrovače,
mezi kterými jsou tři sítě a na jednom z nich je externí spoj. Mým záměrem bylo sledovat, jak se bude
plnit a měnit směrovací tabulka na základě činnosti protokolu RIP na každém uzlu a při výpadku
některého ze spojů. Částečně jsem vycházel z informací v [5].
Protože už nemám v síti žádný koncový uzel, ztrácí smysl mít spuštěného démona pro
automatickou konfiguraci (směrovače se nastaví napevno a ohlášení jiných směrovačů ignorují). Aby
měly všechny uzly sítě přehled o dostupnosti dalších sítí a podsítí, je nutné na nich spustit nějaký
dynamický směrovací protokol, pomocí kterého si budou vyměňovat informace. Zvolil jsem protokol
RIPng (algoritmus distance-vector), který vychází z RIPv2 pro IPv4 a funguje de facto stejným
způsobem, jen zpracovává IPv6 prefixy a adresy. Bližší popis algoritmu RIP najdete v [3].
V základním schématu sítě tedy každý ze směrovačů „vidí“ dvě přímo připojené podsítě,
směrovač BSD pak navíc ještě síť externí. Vzájemnou komunikací (výměnou svých směrovacích
tabulek) by se měly od svých sousedů dozvědět informace i o sítích, které k nim nejsou přímo
připojeny a získat cestu, kterou by měly do této sítě pakety posílat. Pokud dojde k přerušení některého
ze spojů, měl by na to protokol RIP reagovat po uplynutí konvergenční doby (do 2 minut, záleží na
nastavení) změnou směrovacích tabulek daného uzlu a začít přenášet pakety do cizích sítí jinudy.
Zkušební síť je omezená možnostmi jednotlivých zařízení, které nedisponují takovou funkcionalitou
jako profesionální směrovače, takže některé funkce fungovaly jen omezeně. Nedostatkem sítě je také
počet pouhých tří uzlů, kde se nedají vytvořit složitější topologie, které by změny ve směrovacích
tabulkách plně prokázaly (vhodnější by byly alespoň 4 uzly).
Nejdříve je potřeba nakonfigurovat počítače ASTRA a STROM jako směrovače. Postup je
stejný jako u vytvoření koncového uzlu (# touch /etc/hostname6.rozhraní, přidání slůvka dns na
řádek ipnodes do souboru /etc/nsswitch.conf) a navíc je potřeba provést konfiguraci jednotlivých
rozhraní směrovače. To je provede editací souboru /etc/inet/ndpd.conf, který v sobě sdružuje
parametry IPv6 rozhraní a nastavení automatické konfigurace (jakým způsobem distribuovat ohlášení
tohoto směrovače dalším uzlům). Předpokládá se totiž, že pokud si nějaký počítač nastavíme jako
směrovač, budeme z něj chtít také posílat připojeným uzlům ohlášení směrovače, aby se měly podle
čeho konfigurovat. Ve zkušební síti jsem této vlastnosti nemohl využít, protože již nezbyl na koncové
uzly prostor, takže směrovače v ní zapojené si vzájemně rozesílaly svá ohlášení, která ignorovali.
Soubor ndpd.conf by měl u směrovače vypadat nějak takto (příklad z počítače ASTRA):
ifdefault AdvReachableTime 30000 AdvRetransTimer 2000
if hme0 AdvSendAdvertisements on
if ip.tun0 AdvSendAdvertisements on
prefix 3ffe:b80:b74:1::/64 hme0
prefix 3ffe:b80:b74:3:a00:20ff:fe88:f8b7/128 ip.tun0
Řádek vždy začíná klíčovým slovem, které určuje oblast, na kterou se bude vztahovat jeho
pokračování. Následuje jméno proměnné oddělené mezerou, její hodnota a tato dvojice se případně
několikrát opakuje. To je použito v prvním řádku, který nastavuje společné časy pro všechna
rozhraní). Řádky dva a tři nastavují posílání směrovacích ohlášení na daném rozhraní (tyto mohly být
v mé síti vypuštěny – zde jsou jen pro názornost). Poslední dva řádky pak nastavují samotný prefix a
jeho délku pro zvolené rozhraní. Poslední prefix (tunelu) by bylo možno konfigurovat i kratší (např.
/64), ale nemá to příliš velký význam vzhledem k dvoubodovému charakteru spoje. Pokud by nebyla
uvedena adresa rozhraní (část za prefixem), rozhraní by ji dostalo odvozenou od IPv4 adresy tunelu,
což jsem prakticky ověřil.
Takováto informace v souboru ndpd.conf znamená, že server je pokládán za směrovač a že je
na něm spuštěn démon ndpd, který se stará o rozesílání ohlášení směrovače koncovým uzlům. Po
startu se na něm spustí také démon in.ripngd, který vykonává totéž, co in.routed v IPv4 implementuje směrovací protokol RIP - ale pro IPv6 rozhraní. Démon in.ripngd je standardní součástí
instalace Solarisu od verze 8. Výše naznačené změny jsme provedl na obou počítačích Sun.
Na mnou testovaném uzlu BSD směrovací protokol standardně nebyl spuštěn. Pro správné
fungování protokolu RIPng jsem jej tedy musel spustit příkazem
# route6d -s -l
strana 71
Ten začal ohlašovat sousedním uzlům své známé cesty včetně externího rozhraní (parametr -l) a
staticky definovaných cest (parametr -s).
Nejdříve jsem RIPng spustil pouze v uzavřené síti se všemi třemi uzly a všemi spoji zapnutými.
Funkčnost celého systému byla dobrá, již chvilku po zapnutí uzlů docházelo k propagování
směrovacích cest, takže šlo v rámci testovací sítě bez problémů dosáhnout z jakéhokoliv na jakékoliv
jiné rozhraní (např. nástrojem traceroute6). Směrovací tabulky se správně naplnily a nevytvořila se
implicitní výchozí cesta na žádném ze směrovačů. Při přerušení libovolného spoje (# ifconfig
rozhraní –inet6 down) se po chvilce směrovací tabulky aktualizovaly a zrušený spoj bylo možno
nahradit dvojicí přeskoků.
Po zapojení externího spojení do Internetu (tunelu do sítě Freenet6) se po síti rozdistribuovala i
informace o této cestě (nicméně ne dál do Internetu – tamější směrovač již RIP správně
nepodporoval). Vytvoření tunelu znamenalo také zásah do směrovacích tabulek mimo činnost
algoritmu RIP – vytvoření implicitní cesty do Internetu na počítači BSD. Ta byla záhy RIPem
rozdistribuována na oba ostatní uzly, takže se mohly připojit k IPv6 Internetu také.
Distribuce implicitní cesty ovšem nefungovala zcela bezchybně - při přerušení některého
z nativních spojů a požadavku na spojení do Internetu z odříznutého uzlu nedošlo k očekávané úpravě
směrovacích tabulek na odříznutém uzlu. Při jednom z testů jsem totiž simulovaně přerušil spojení
mezi uzly BSD a STROM. Na uzlu BSD bylo spojení přerušeno příkazem
# ifconfig lnc0 inet6 down
Analogicky jsem jej zastavil i na počítači STROM:
# ifconfig dmfe0 inet6 down
BSD
ep0
Freenet 6
gif0
lnc0
3ffe:b80:b74:1::/64
hme0
dmfe0
ASTRA
STROM
ip.tun0
ip.tun0
3ffe:b80:b74:3::/128
Výchozí cesta (default) správně nastavená směrovacím algoritmem.
Výchozí cesta (default), kterou bylo nutno zadat ručně.
Obrázek 15: Schéma sítě při simulovaném výpadku jednoho ze spojů
strana 72
Co se po vypnutí spoje stalo? Směrovací tabulka STROMU hned po výpadku již neobsahovala
vypnutou cestu, ale ještě nebyla aktualizována směrovacím protokolem, který by měl sestavit náhradní
cestu přes tunel. Důvodem byla příliš krátká doba, kdy ještě nedošlo k vypršení pojistných časovačů.
# netstat -r
Routing Table: IPv6
Destination/Mask
--------------------------astra3.ipv6.vse.cz
fe80::9266:4d58
::/96
localhost
Gateway
--------------------------strom3.ipv6.vse.cz
fe80::9266:2727
strom.vse.cz
localhost
Flags Ref
Use
If
----- --- ------ ----UH
1
1 ip.tun0:1
UH
1
0 ip.tun0
U
1
0 ip.atun0
UH
1
0 lo0
Po několika minutách, kdy RIPng zaregistroval výpadek spoje a upravil dostupné cesty,
vypadala směrovací tabulka počítače STROM takto:
Routing Table: IPv6
Destination/Mask
--------------------------3ffe:b80:2:7df9::1
VSE-TEST.tsps1.freenet6.net
astra3.ipv6.vse.cz
fe80::9266:4d58
::/96
3ffe:b80:b74:1::/64
3ffe:b80:b74::/48
localhost
Gateway
--------------------------fe80::9266:4d58
fe80::9266:4d58
strom3.ipv6.vse.cz
fe80::9266:2727
strom.vse.cz
fe80::9266:4d58
fe80::9266:4d58
localhost
Flags Ref
Use
If
----- --- ------ ----UGH
1
0 ip.tun0
UGH
1
0 ip.tun0
UH
1
1 ip.tun0:1
UH
1
0 ip.tun0
U
1
0 ip.atun0
UG
1
0 ip.tun0
UG
1
0 ip.tun0
UH
1
0 lo0
Je zřejmé, že směrovací tabulka neobsahuje žádnou implicitní (default) cestu. I když měl uzel
dostupný tunel, mohl jej použít pouze pro směrování ve vnitřní síti, protože se mu zrušením spoje
ztratila i implicitní (default) cesta, která již nebyla znovu distribuována. Konektivita ve zkušební síti
až na výstupní bod tunelu byla zachována, ale jakékoliv spojení dále do Internetu končilo na
neschopnosti odříznutého uzlu přesměrovat neznámé odchozí pakety do tunelu. Problém se mi
podařilo obejít ručním zadáním implicitní cesty na uzlu STROM, což ovšem není systémové řešení.
Směrovací tabulka STROMU po ručním zadání cesty a traceroute s dvěma přeskoky v základní
síti vypadá následovně:
# route add -inet6 default astra3.ipv6.vse.cz
# netstat -r
Routing Table: IPv6
Destination/Mask
Gateway
--------------------------- --------------------------3ffe:b80:2:7df9::1
fe80::9266:4d58
VSE-TEST.tsps1.freenet6.net fe80::9266:4d58
astra3.ipv6.vse.cz
strom3.ipv6.vse.cz
fe80::9266:4d58
fe80::9266:2727
::/96
strom.vse.cz
3ffe:b80:b74:1::/64
fe80::9266:4d58
3ffe:b80:b74::/48
fe80::9266:4d58
default
astra3.ipv6.vse.cz
localhost
localhost
Flags Ref
Use
If
----- --- ------ ----UGH
1
0 ip.tun0
UGH
1
0 ip.tun0
UH
1
1 ip.tun0:1
UH
1
0 ip.tun0
U
1
0 ip.atun0
UG
1
0 ip.tun0
UG
1
0 ip.tun0
UG
1
0
UH
1
0 lo0
# traceroute -A inet6 www.kame.net
traceroute: Warning: kame220.kame.net has multiple addresses; using
2001:200:0:4819:210:f3ff:fe03:4d0
traceroute: Warning: Multiple interfaces found; using
3ffe:b80:b74:3:203:baff:fe05:214a @ ip.tun0:1
traceroute to kame220.kame.net (2001:200:0:4819:210:f3ff:fe03:4d0), 30 hops max,
60 byte packets
1 astra3.ipv6.vse.cz (3ffe:b80:b74:3:a00:20ff:fe88:f8b7) 1.745 ms 1.476 ms
2 bsd1.ipv6.vse.cz (3ffe:b80:b74:1:2a0:24ff:fe3d:aa76) 2.067 ms 1.936 ms
3 3ffe:b80:2:7df9::1 121.018 ms 128.453 ms 127.945 ms
4 VIAGENIE.r00.snjsca03.us.b6.verio.net (2001:218:0:80:1:840:1:e) 119.063 ms
5 3ffe:8000:ffff:b::1 433.351 ms 566.694 ms *
6 2001:200:0:1802:2a0:ccff:fe73:4413 683.025 ms 697.287 ms 684.274 ms
7 pc6.otemachi.wide.ad.jp (2001:200:0:1800::9c4:0) 682.065 ms 669.543 ms
8 pc1.notemachi.wide.ad.jp (2001:200:0:6c01:290:27ff:fe3a:d8) 652.153 ms
9 pc3.yagami.wide.ad.jp (2001:200:0:1c04::1000:2000) 708.588 ms 680.056 ms
10 2001:200:1b0:1000::2000:1 707.419 ms 668.673 ms 708.330 ms
11 paradise.kame.net (3ffe:501:4819:2000:2e0:18ff:fe98:f19d) 675.321 ms
12 2001:200:0:4819:210:f3ff:fe03:4d0 795.283 ms 706.582 ms 701.917 ms
strana 73
Přes velké úsilí se mi nepodařilo směrovače přimět, aby si implicitní cestu předaly při výpadku
některého spoje správně. Ostatní prefixy cest se předávaly v pořádku, nicméně výchozí cesta to
dokázala pouze při prvním zadání. Je možné, že jde o menší nedokonalost v implementaci RIPu na
Solarisu, kterou bude potřeba v dalších verzích odstranit. Ve všech ostatních mnou testovaných
ohledech se implementace chovaly správně a podle očekávání.
Implementace a nasazení distance-vector směrovacího algoritmu se ukázala až na některé
specifické topologické záležitosti jako málo problematická záležitost a s použitím kvalitnější
implementace (z KAME, Zebra apod.) by mohla být aplikovatelná do IPv6 sítě ihned.
9.3.4. Služby protokolu http
Po otestování a ustálení funkčnosti konektivity jsem se zaměřil na instalaci a testování
některých běžně používaných síťových aplikací na IPv6 uzlech.
Zřejmě nejznámější a nejpoužívanější síťovou službou dnešního Internetu je World Wide Web.
Jde o client/server službu založenou na protokolu http, kde webové servery poskytují prohlížečům na
počítačích uživatelů podle vyžádání různý obsah. Tato služba (stejně jako další mnou testované) bude
stejně jako dnes v IPv6 nezbytnou a bude třeba ji umět dobře implementovat, jak na straně serveru, tak
na straně klienta.
Velmi používaným webovým serverem je projekt Apache vyvíjený s otevřeným zdrojovým
kódem (open-source), který si pro IPv4 může zkusit nainstalovat každý, kdo disponuje potřebnou
platformou. Distribuuje se jak v přeložené binární formě, tak ve zdrojových kódech a je možné jej
podle potřeby upravit. Funkčně je velmi bohatý a nabízí možnost zahrnutí do chodu webového serveru
mnoho doplňků (SSL šifrování, podporu skriptování, konverzní moduly a jiné). V rámci projektu
KAME doplnili tvůrci do zdrojových kódů původního IPv4 Apache podporu pro IPv6 adresy, takže jej
lze s plnou funkčností využívat i na IPv6 sítích.
Vyzkoušel jsem zprovoznění IPv6 webového serveru také na uzlu ASTRA v testovací síti. Pro
instalování je velmi vhodné použít překladače GNU cc (gcc) a GNU make (make). Mechanismus
překladu a instalace je mimo téma této práce, takže popíši jen věci související s IPv6. Server je
distribuován v originálních zdrojových kódech zkomprimovaných do jednoho souboru (dá se stáhnout
z www.apache.org). K němu lze získat z projektu KAME diferenční soubor (například jména apache1.3.19-v6-20010309a.diff), který obsahuje rozdíly, které je pro podporu IPv6 nutno ve zdrojových
kódech provést. Oba tyto soubory je potřeba stáhnout na cílový server a provést dekompresi:
# gzip –d jmeno_souboru.tar.gz
# tar –xvf jmeno_souboru.tar
Adresář se zdrojovými kódy bude možná nutno přejmenovat, aby jeho jméno odpovídalo
cestám uvedeným v souboru .diff (v mém případě bylo potřeba přejmenovat adresář apache_1.3.19
na apache13). Pokud máme k dispozici správně nainstalovaný překladač a potřebné knihovny, je
možné provést úpravu zdrojových kódů originální verze Apache podle úprav z KAME:
# patch < jmeno_souboru_s_rozdily.diff
Tento příkaz upraví automaticky všechny příslušné soubory. Přímo na počítači ASTRA byly
s tímto příkazem problémy, jeho implementace v Solarisu není v souladu s očekáváním tvůrců KAME.
Byl jsem tedy nucen provést úpravy na počítači BSD (kde příkaz patch funguje správně), odkud jsem
aktualizované zdrojové kódy na ASTRU zkopíroval zpět. Překlad kódů do binární formy se vykoná
následující trojicí příkazů:
# sh ./configure.v6 --enable-rule=INET6
# make
# make install
Příkazu ./configure.v6 je možné vložit celou řadu dalších doplňujících parametrů (další
podporované moduly, adresáře, kam se má nainstalovat a podobně), ty jsou však shodné jako při
instalaci na IPv4, takže je zde nebudu rozebírat.
Nainstalovaný webový server lze po úpravě konfiguračních souborů spustit příkazem
strana 74
# /usr/local/apache/bin/apachectl start
Tím se na TCP portu 80 objeví vyčkávající démon, který bude http požadavky vyřizovat
(výsledný stav je uveden v přehledu čekajících serverů na konci kapitoly). Instalaci webového serveru
jsem úspěšně dokončil bez větších problémů.
Pokud by bylo potřeba na IPv6 zprovoznit bezpečnou webovou komunikaci přes protokol https,
je to také možné, nicméně vzhledem k úzké vazbě SSL knihoven na IP adresy je potřeba pro IPv6
zkompilovat také tuto knihovnu. Pro web cache a proxy servery je k dispozici soubor s úpravami i pro
hojně užívaný server squid. Ten jsem vzhledem k malému rozsahu sítě netestoval.
Instalaci jsem ověřil pomocí grafického prohlížeče Mozilla, který je rovněž open-source
projektem a IPv6 standardně podporuje. Mozilla se ukázala být prohlížečem stabilním a funkčním pro
řadu mnou zkoušených IPv4 a IPv6 webů. Podporuje zadávání číselných IPv6 adres v URL a správně
se dotazuje do DNS i na IPv6 adresy. Pokud má některý uzel (např. www.kame.net) jak AAAA, tak i
A záznam, použije se podle standardního nastavení IPv6 adresa.
Bohužel jsem neměl vhodné podmínky ke srovnání rychlosti obou protokolů, protože měření by
byla zkreslena tunelem přes Freenet6 tak, že by je nešlo použít. Nemohl jsem porovnat ani rychlost
grafického zobrazování lokálních stránek, protože jsem Mozillu spouštěl na počítači BSD, kde nebyla
k dispozici grafická konzole, takže jsem musel pro zobrazení využít forwardování na jiný X11 server
v síti (pracovní stanice s Windows 98), který není příliš dobrý (ale pro základní použití stačí).
Obrázek 16: Přístup prohlížečem Mozilla na právě nainstalovaný webový server astra.ipv6
Mozilla je k dispozici ve zdrojových kódech a v přeložené formě pro většinu obvyklých
platforem (včetně Microsoft Windows), takže její použití je poměrně univerzální. Nemusí mít sice
plnou funkčnost například Microsoft Internet Exploreru (Mozilla je stále ve vývoji), což může být
argumentem proti masovému nasazení na koncové stanice. Doufám, že budoucí verze Mozilly budou
spolu s vývojem a přechodem na IPv6 stále funkčně bohatší, aby mohla být vydána stabilní verze,
která by byla s Internet Explorerem srovnatelná co do rychlosti, stability a schopností.
strana 75
Obrázek 17: Přístup webovým prohlížečem Mozilla na server www.kame.net
Z dalších klientských http aplikací jsem úspěšně vyzkoušel upravené (způsobem naznačeným u
kompilace serveru apache) programy lynx (textový prohlížeč) a wget (stahování souborů dle URL).
Problémy jsem nezaznamenal, nicméně u těchto dvou nejde o kritické aplikace, jejichž absence by
znamenala problémy.
Webové služby jsou na IPv6 podporovány dle mého názoru poměrně dobře. Existence IPv6
doplňků (patchů) do profesionálního serveru Apache znamená, že jeho funkčnost z IPv4 je
přenositelná také na IPv6, takže se není třeba obávat omezení. Menší nedostatky jsou v oblasti klientů,
nicméně Mozilla je pro většinu platforem velmi dobrou alternativou. Nové verze Internet Exploreru již
IPv6 částečně podporují (netestoval jsem z důvodu absence platformy Windows v testovací síti), takže
zde bych se větších obtíží neobával. Pro uživatele bude vhodný grafický prohlížeč na IPv6 pro jejich
platformu zřejmě vždy dostupný. Celkově mohu hodnotit podporu protokolu http (servery, cache,
klienti) jako dobrou a již dnes použitelnou.
9.3.5. Služby vzdáleného přihlášení
Další oblastí, kde je podpora IPv6 nezbytná, je vzdálené přihlášení na jiný počítač. To může mít
různou podobu, která velmi závisí na konkrétní platformě. Základní variantou je terminálové
přihlášení k textové konzoli, které je v nejjednodušší formě známé jako telnet. Na unixových
počítačích se o tyto služby stará na serverové straně démon in.telnetd. Vzhledem k malé
bezpečnosti této služby (data jsou přenášena v otevřené formě) se dnes již často využívá šifrovaného
přenosu pomocí protokolu Secure Shell (SSH), na serveru jej zajišťuje démon sshd.
Jak telnet, tak SSH implementace pro protokol IPv6 jsem v testovací síti vyzkoušel. Démon
in.telnetd pro IPv6 je ve standardní instalaci Solarisu k dispozici, takže jsem mezi uzly ASTRA a
STROM mohl zkoušet vzdálené přihlášení nativně po IPv6 (přehled o existujících spojeních lze získat
příkazem # netstat -a -f inet6). Šlo o běžné terminálové připojení, na kterém jsem nezaznamenal
žádné rozdíly oproti běžnému telnetu (ani jsem je neočekával).
strana 76
Pro použití přihlášení pomocí protokolu SSH jsem zvolit volně šiřitelnou implementaci
OpenSSH, která se distribuuje ve zdrojových kódech. Podporu protokolu IPv6 má již v sobě delší
dobu zabudovánu, takže není potřeba zvlášť upravovat zdrojové kódy. Pro správné fungování je třeba
mít nainstalovánu knihovnu OpenSSL. Překlad a instalace samotného SSH se provede těmito příkazy
(s výchozím nastavením všech parametrů a adresářů):
# ./configure
# make
# make install
Konfigurační informace se dají měnit v souboru /etc/sshd_config. Po spuštění démona sshd
začne tento na TCP portu 22 protokolu IPv4 i IPv6 „naslouchat“ (TCP port je ve stavu LISTEN) a je
možné se přes něj při splnění všech autentizačních podmínek přihlásit do systému.
Klientskou částí SSH je řádkový program ssh, jehož parametrem je uživatel a vzdálený počítač,
na který se přihlašujeme. Pokud chceme při přihlašování použití protokolu IPv6 vynutit (daný server
má jak IPv4, tak IPv6 adresu), lze použít parametr ssh –6 (analogicky pak ssh –4 použije pouze IPv4
rozhraní). Pokud je k danému doménovému jménu v DNS pouze A záznam nebo pouze AAAA
záznam, použije se protokol odpovídající verze automaticky. Fungování vzdáleného přihlášení je i
v tomto případě shodné jako na protokolu verze 4 a je bezproblémové.
SSH i telnet jsou vzdálená přihlášení k textovému uživatelskému rozhraní. V rámci projektu
KAME byly sestaveny i úpravy pro aplikaci vzdáleného grafického přihlášení VNC (Virtual Network
Computing) mezi různými operačními systémy. Jde o úpravy (patche) k oficiálním zdrojovým kódům
verze 3.3.3 daného programu. Jde opět o klient/server aplikaci, kde z klienta lze ovládat grafické
rozhraní na serveru (celý desktop). Mezi počítači se přenáší se pohyby myši a stisky klávesnice
v jednom směru a změny grafického výstupu v druhém směru. Záleží na každém operačním systému,
jakým způsobem je grafické přihlášení řešeno (zdali se jedná o ovládání jedné pracovní plochy nebo
jich lze vytvořit více).
Na počítači ASTRA jsem stáhl zdrojové kódy jak oficiálního projektu, tak doporučené úpravy,
aplikoval je a program úspěšně přeložil. Vzhledem k absenci grafických rozhraní na uzlech v testovací
síti jsem neměl možnost aplikaci vyzkoušet v praxi (potřebuji alespoň dvě grafická rozhraní).
Vzhledem k bezproblémové funkčnosti na všech platformách na IPv4 bych ovšem nečekal výraznější
problémy ani zde a dle tato mého názoru užitečná aplikace by měla jít použít.
9.3.6. Služby přenosu souborů
Další z věcí, kterou je nutno při používání sítě často provádět, je přenos souborů mezi dvěma
uzly. K tomuto účelu lze mimo mnoha jiných použít služby FTP a SCP. První je tradiční nešifrovaná
služba File Transfer Protocol (procházení vzdálených adresářů, nahrávání a stahování souborů), druhá
je distribuována společně se službami SSH a slouží k šifrovanému přenosu jednotlivých souborů. Na
počítačích s operačním systémem Solaris je opět IPv6 verze FTP serveru nainstalována standardně. Na
počítači BSD není FTP server standardně spuštěn z bezpečnostních důvodů, ale je možné volitelně
některý s dostupných IPv6 serverů stáhnout a po aplikaci IPv6 úprav přeložit (například wu-ftpd). Já
jsem pro své pokusy použil standardní in.ftpd ze Solarisu. FTP klient byl standardně dostupný na
všech počítačích v síti, ovládá se interaktivně.
SCP je součástí instalace OpenSSH, jejíž instalaci jsem popsal v předchozí podkapitole.
Serverovou částí je opět démon sshd, klientem je řádkový program scp, kterému se předají dva
parametry – umístění zdrojového souboru a umístění cílového souboru (včetně identifikace lokality v
síti). Opět je možné použít parametry –4 a –6 k přímé specifikaci verze IP protokolu, který se má
použít. Jak FTP, tak SCP fungoval při zkouškách podle očekávání a bez jakýchkoliv problémů při
procházení adresářů a přenosu malých i velkých souborů.
Na službách přenosu souborů jsem také rozhodl změřit přenosové rychlosti, které jsou po
jednotlivých protokolech dosažitelné. Měřil jsem na spoji mezi počítači ASTRA a BSD přes
rozbočovač, od kterého byly odpojeny všechny ostatní uzly, aby nemohlo dojít k narušení měření
jinými datovými toky. Použitou technologií druhé vrstvy byl Ethernet o rychlosti 10 Mbit/s poloviční
duplex, přenášel jsem několikrát jeden soubor o velikosti 56 662 555 bajtů. Naměřené časy pro obě
služby a obě verze protokolů jsou uvedeny v tabulce:
strana 77
Pokus FTP verze 4
1:05:35 s (846,69 kB/s)
1.
1:06:08 s (837,30 kB/s)
2.
X
3.
FTP verze 6
1:06:43 s (832,99 kB/s)
1:06:50 s (832,13 kB/s)
X
SCP verze 4
SCP verze 6
1:50 s
1:51 s
1:49 s
1:45 s
1:44 s
1:47 s
Z výsledků je zřejmé, že přenosové rychlosti jsou velmi podobné na obou verzích protokolu. U
použití FTP, které bylo rychlostně omezeno shora pouze rychlostí přenosového média, je zřejmý lehký
nárůst času při použití IPv6, která dle mého názoru odpovídá delším hlavičkám IPv6 paketů. MTU
Ethernetu je 1500 bajtů, soubor tedy putoval přibližně v 35000 paketech, kde v IPv4 měly hlavičky
velikost 20 bajtů a IPv6 hlavičky velikost 40 bajtů. 20 bajtů navíc pro každý paket je pro celý přenos
přibližně 700 KB dat navíc, takže přenos v IPv6 by měl trvat průměrně o necelou jednu sekundu déle
než v IPv4. Tomu se naměřené časy blíží, musím ovšem podotknout, že kolísání rychlosti při
přenosech mohly ovlivnit i jiné skutečnosti (kolize rámců apod.), kterých by ovšem nemělo být
mnoho.
Z výsledků SCP služeb mě samotného udivilo výrazné prvenství šifrovaného přenosu po IPv6 o
5 sekund. Tyto rychlosti již nejsou ovlivněny rychlostí přenosového spoje, ale výkonností CPU obou
uzlů, se kterou jsou schopny šifrovat a dešifrovat přenášená data. Vliv nárůstu hlaviček IPv6 protokolu
je zde tedy zanedbatelný a rozdíl v rychlostech si lze vysvětlovat například rozdílným použitým
mechanismem šifrování, který mezi sebou uzly dojednaly. Podrobnější příčiny této neshody bohužel
nejsem schopen zjistit, mohlo jít i o náhodné skutečnosti, které IPv4/6 přenosy ovlivnily.
Z hlediska funkčnosti jsou pro IPv6 bez problémů dostupné základní služby přenosu souborů
(SSH i FTP) a to jak serverové, tak klientské implementace. Z hlediska výkonu je při přenosu po
přímém spoji bez šifrování znát drobný rozdíl v rychlosti způsobený (dle mého názoru) větší velikostí
hlaviček v IPv6, který je ale pro uživatelský komfort téměř neznatelný.
Při přenosech s použitím šifrování velmi záleží na výkonu šifrovacích programových rutin a
obou koncových uzlů, takže se pak hlavičkový rozdíl dle mých měření vůbec neprojevil (a naopak se
projevily vlivy jiné). Dá se očekávat, že při průchodu složitější topologií sítě (směrovače, tunely,
souběh s jinými daty) se rozdíl mezi verzemi obou protokolů smaže také a z tohoto důvodu není třeba
brát delší hlavičku IPv6 jako nevýhodu - v provozu se rozdíl nepozná.
9.3.7. Poštovní služby
Velmi důležitou službou je také přenos elektronické pošty. V Internetu se pro tyto účely používá
protokol SMTP, pomocí kterého si servery posílají dopisy mezi sebou. Při implementaci poštovních
služeb do IPv6 sítě je potřeba v každém případě zavést aplikační bránu, která bude schopna výměny
pošty s poštovními systémy v IPv4 síti. Důvodem je zachování celistvosti poštovního systému pro
uživatele.
V rámci sítě VŠE existuje řada poštovních serverů, na kterých mají uživatelé své poštovní
schránky. Ty se při požadavku o komunikaci s poštovními servery mimo VŠE obrací na centrální
poštovní server vse.vse.cz, přes který odchází přes něj veškerá pošta do venkovních sítí a přichází na
něj veškerá pošta zvenku. Doručování na lokální servery se pak děje podle nastavené tabulky
poštovních serverů.
Tato konfigurace je vhodná pro zapojování jak poštovních serverů, které jsou finálními
z hlediska cesty pošty, tak pro zapojování různých poštovních bran, které přeposílají poštu jinam.
Brány mohou fungovat jako filtrovací (například antivirový systém) nebo jako prostředník mezi
dvěma různými sítěmi (například aplikační překladač z IPv4 do IPv6).
Způsoby zapojení IPv6 sítě do poštovních služeb jsou v zásadě dva – s použitím aplikační brány
jako prostředníka nebo s pomocí IPv6 rozhraní přímo na vse.vse.cz.
První způsob je následující. Dejme tomu, že v IPv6 síti budou někdy v budoucnu dva poštovní
servery (A a B), z nichž pouze jeden (A) bude mít přístup do IPv4 sítě a že centrální mailserver
vse.vse.cz bude fungovat pouze na IPv4. Server B bude komunikovat pouze po IPv6 protokolu. Aby
mohla být celosvětová pošta funkční na všech uzlech, je nutné nastavit servery takto:
- B: výchozí cesta pro veškerou nelokální poštu je server A
- A: výchozí cesta pro veškerou nelokální poštu je server vse.vse.cz s výjimkou pošty, která
směřuje přímo na server B
strana 78
-
vse.vse.cz:
transportní tabulka ukazuje, že veškerá pošta na servery A a B je posílána na server
A
Poštovní server A vedle pošty po své koncové uživatele je zároveň bránou pro doručování na
uzel B (a obecně jakýkoliv další poštovní uzel v IPv6 síti) a pro veškerou odchozí poštu celé IPv6 sítě.
Nevýhodu tohoto způsobu spatřuji ve vytváření dalších poštovních podsystémů a tříštění jednotné a
jednoúrovňové sítě do komplikovanější hierarchie (vse.vse.cz by přestalo být skutečně centrálním
uzlem pro veškerou poštu), která by byla náročná na konfiguraci a správu. Nicméně by mohlo být
vhodné v počáteční fázi implementace IPv6 služeb, protože vse.vse.cz nemusí mít pro IPv6 žádnou
podporu a nebylo by třeba (s výjimkou transportní tabulky) jeho konfiguraci měnit.
Druhý způsob je koncepčně správnější, vyžaduje ale instalaci dvojího protokolu na vse.vse.cz.
To by pak bylo dále centrálním uzlem, z nějž by byly dostupné všechny poštovní servery, ať již IPv4
nebo IPv6. Dopisy po obou protokolech by na něj přicházely po příslušném rozhraní. Na základě
dotazu do DNS nebo adresy v transportní tabulce by se podle typu adresy dopis poslal buď na IPv4
server nebo na IPv6 server. Řešení by nevyžadovalo explicitní konfiguraci IPv6 poštovní sítě ani
úpravu v transportní tabulce na vse.vse.cz.
V počáteční fázi (dokud bude školní IPv6 síť malá a špatně geograficky dostupná) by mohlo být
IPv6 rozhraní řešeno jako tunel do nativní sítě. Ten by bylo možné realizovat již dnes (operační
systém je Sun Solaris 7), například do zkušební sítě.
Vzhledem k důležitosti serveru vse.vse.cz pro celou síť VŠE a možným problémům při
konfiguraci tunelu a nového rozhraní jsem tento pokus neprovedl a naznačil jej pouze v teoretické
rovině. Konfigurace nového rozhraní by byla velkým zásahem do provozního serveru VŠE (nutná
instalace IPv6 doplňku - patche do jádra systému) ve správě outsourcingové firmy a možný výpadek
doručování pošty by mohl být velikou komplikací pro skutečný provoz školy. Dosahem by tato
operace výrazně přesáhla hranice mé testovací sítě, čemuž jsem se chtěl vyhnout.
Z hlediska software je možné jako SMTP server na IPv6 protokol použít standardní program
sendmail v zásadě pro libovolnou platformu. V Solarisu 8 je k dispozici ihned po instalaci, což jsem
ověřil posláním dopisu pomocí IPv6 programu telnet na TCP port 25. Pro BSD díky úpravám projektu
KAME existuje sendmail standardně také.
Sendmail je distribuován je ve zdrojových kódech, na které je potřeba aplikovat diferenční
soubory pro verzi 6 a výsledné programy přeložit kompilátorem. Stejný způsob distribuce a instalace
je použit i pro nyní populární SMTP server postfix autora Wietse Venemy, který pro svou snažší
konfigurovatelnost a dobrý výkon na poštovních serverech stále častěji nahrazuje sendmail.
Posílání pošty z testovací IPv6 sítě ani jejímu příjmu tamtéž tedy v zásadě nic nebrání. Pro
úplný provoz na VŠE je potřeba zajistit přiřazení IPv6 rozhraní počítači vse.vse.cz, správné
zavedení IPv6 adresy do DNS vedle té stávající a případnou úpravu MX záznamu v DNS tak, aby
dotazující servery dostaly adresy ve správné verzi protokolu (dle mého názoru by toto mělo fungovat
automaticky). Implementace SMTP serverů jsou k dispozici (alespoň pro unixové systémy) stejně
kvalitní, jako v IPv4 světě, takže o funkčnost není třeba mít obavy ani v současné době.
9.4.
Shrnutí a závěr testování
9.4.1. Zhodnocení provozu uzlů
Při testování se většina zkoušených mechanismů ukázala jako funkční podle očekávání a
deklarace výrobce. Bezproblémový byl přenos IPv6 paketů po Ethernetu a jeho nativní koexistence
s protokolem IPv4 na síťových prvcích první a druhé vrstvy. Provoz obou protokolů probíhal bez
narušení druhého.
Podpora v testovaných operačních systémech se ukázala jako reálně použitelná, snadno
konfigurovatelná a s potřebnými doprovodnými vazbami na jiné části operačního systému. Na obou
systémech (BSD a Solaris) se dalo s IPv6 rozhraními pracovat analogickým způsobem jako s IPv4
včetně základní konfiguračních příkazů jako netstat, route, ifconfig a dalších. Jako velmi snadné
se ukázalo být vytvoření tunelu po IPv4 infrastruktuře.
U počítače BSD jsem si potvrdil informace o velmi kvalitní implementaci projektu KAME,
z níž jsem ani neměl možnost řadu vlastností vyzkoušet (např. mobilitu nebo kvalitu služby). U obou
Solarisů jsem původně očekával podporu jen základní, ale ukázala se být širší a velmi snadno ji šlo
rozšiřovat přenášením dalších aplikací projektu KAME a překladem na tuto platformu (webový server
strana 79
apache). Podle výrobců dalších IPv6 síťových produktů (například směrovacího software Zebra) je
Solaris také podporován, takže s doplňkovými službami by měly být problémy pouze týkající se
přenosu na jinou platformu. Nativní podpora přímo v jádře základní instalace je samozřejmě lepší a
v tomto ohledu má BSD navrch, proto jsem jej také použil jako výstupní bod externího tunelu a
směrovač s nejsložitějším nastavením.
Podpora směrování protokolem RIPng se ukázala jako fungující na všech uzlech, s malými
nedostatky na systému Solaris (propagace implicitní cesty). Distribuce ostatních směrovacích
informací fungovala analogicky, jako ve verzi 4. Pro směrování v malé místní síti je RIPng dostatečný,
pokud bychom chtěli řídit provoz ve složitější topologii směrovačů, bylo by vhodné použít například
OSPF, který však na Solarisu není výrobcem v současné verzi podporován (bylo by jej nutno přenést
z jiné platformy a instalovat speciální software). Směrováni probíhalo správně i v tunelech a to jak
manuálně konfigurovaných, tak automatických.
Velmi dobře jsou implementovány mechanismy automatické konfigurace na obou systémech,
takže si lze usnadnit práci se zapojováním koncových počítačů. Rozdělování přiděleného prefixu
délky /48 na menší sítě a přidělování /64 prefixů pro jednotlivá rozhraní je snadnou záležitostí jednoho
řádku v konfiguračním souboru. Stabilně fungoval i algoritmus vytváření EUI-64 části IP adresy
z MAC adresy síťové karty, takže jsem tyto automaticky „vygenerované“ adresy mohl vložit jako
pevné záznamy do DNS. Zatím není vyřešeno bezstavové (bez použití DHCP) vyhledání DNS
serveru, takže nastavení jeho adresy na testovaných uzlech jsem provedl staticky a pouze pro IPv4
protokol (protože všechny uzly byly dvouprotokolové).
Podpora základních aplikačních služeb (web, pošta, přenos souborů a vzdálené přihlášení) je
nyní na vcelku dobré úrovni a zvláště v oblasti serverových služeb je funkčně srovnatelná s IPv4
implementacemi. Problémem by mohla být složitější instalace (je nutno upravovat zdrojové kódy),
zatím malá podpora komerčními aplikacemi a poměrně málo uživatelsky příjemné rozhraní
klientských aplikací. Existují samozřejmě výjimky (např. dobrý webový prohlížeč Mozilla), nejde ale
o v současnosti masově používané aplikace (např. MS Outlook), takže uživatelé by museli při
přechodu sítě na IPv6 v současné době změnit i aplikace, na které jsou zvyklí. Při zavádění poštovních
služeb je potřeba dobře promyslet integraci s IPv4 poštovními servery, která bude nutná již od prvního
nasazení.
Přehled všech běžících TCP služeb na počítači ASTRA je uveden níže:
# netstat –a –f inet6
TCP: IPv6
Local Address
Remote Address
Swind Send-Q Rwind Recv-Q
--------------------- ----------------------- ----- ------ ----- -----*.ftp
*.*
0
0 24576
0
*.telnet
*.*
0
0 24576
0
*.smtp
*.*
0
0 24576
0
*.22
*.*
0
0 24576
0
*.80
*.*
0
0 24576
0
State
---------LISTEN
LISTEN
LISTEN
LISTEN
LISTEN
Celková funkčnost sítě splnila a v jistých ohledech i předčila mé očekávaní. Z hlediska
konektivity na třetí vrstvě není s IPv6 žádný problém ani s nativními spoji, ani s tunely. Koexistence
s IPv4 infrastrukturou je bezproblémová. Mnou testované implementace se ukázaly jako stabilní a dle
mého názoru jsou schopné rutinního nasazení do běžné IPv6 sítě, kde mohou bez problémů trvale
běžet i základní provozní služby. Je tedy možné i při použití dnešního stavu věcí sestavit jakési jádro
budoucí IPv6 sítě, které může být připraveno k poskytování nativních IPv6 služeb nebo k dalšímu
testování jiných platforem a v budoucnu vyvinutých implementací a aplikací.
9.4.2. Další možnosti výzkumu
Další funkčnost IPv6 (mobilita, externí tunelování) by se dala ověřit při vytvoření více
„ostrovů“ IPv6 sítí v různých lokalitách VŠE nebo při hlubší spolupráci s ostatními institucemi
CESNETu. Pro tyto účely by bylo vhodné zřídit co nejdříve přímé tunelové propojení do nejbližšího
přístupového bodu CESNETu a požádat jej o přidělení adresního prefixu, případně se trvaleji zapojit
do práce výzkumné skupiny IPv6. Připojení VŠE do výzkumu i s malou testovací sítí by mohlo být
vhodné, podmínkou je ovšem její trvalé zřízení a vyčlenění lidských zdrojů, prostor a případně
některých síťových prvků (switche, PC směrovače). Tyto činnosti jsou mimo mé dosavadní možnosti a
strana 80
mimo rozsah této diplomové práce. Nic ovšem nebrání tímto směrem ve výzkumu dále pokračovat a
zaměřovat se na testování pokročilých vlastností IPv6 – například bezpečnosti a mobility. Ve
složitějších topologiích by se také lépe otestovala stabilita a robustnost směrovacích protokolů pro
velké sítě (např. OSPF).
Důležité je také dále sledovat nové verze často používaných síťových aplikací, zdali již
nepodporují IPv6. Pokud ano, tak jak kvalitně a v jakém rozsahu, pokud nepodporují, pak je třeba
zjistit, kdy výrobce podporu plánuje.
Dalším důležitým krokem zkoumání by měla být implementace stabilní překladové brány mezi
IPv4 a IPv6 světem – řešení pomocí duálních protokolů není dlouhodobě únosné (zejména z důvodu
potřeb IPv4 adres). Navazujícím krokem by pak mohlo být nasazení koncových uzlů, které již IPv4
nepodporují vůbec a zkoušení tunelování osamělých IPv6 uzlů mimo tyto IPv6 ostrovy.
Mnou netestovaným, ale z hlediska sítě velmi významným prvkem je profesionální směrovač
(Cisco, Nortel apod.). Implementace jejich operačního systému je také velmi důležitá a je nutné ji
vyzkoušet. Pro směrovače firmy Cisco již existuje oficiální podpora IOSu s některými IPv6 funkcemi
od verze 12.2(2)T, kterou jsem však neměl pro účely testování k dispozici, takže jsem nemohl vhodný
Cisco směrovač do zkušební sítě zařadit. Po získání IPv6 verze IOSu by bylo ovšem vhodné co
nejdříve otestovat i její schopnosti. Podle informací, které se mi podařilo získat, je její současná
funkčnost dobrá, nicméně pouze na základní úrovni (fáze 2 dle interních specifikací Cisca) a pro
páteřní sítě zatím nevhodná.
V budoucnu velmi používanou platformou bude bezesporu stejně jako v současnosti operační
systém Windows firmy Microsoft. Tento druh uzlu nebyl v testovací síti obsažen, protože současná
podpora ze strany Microsoftu obsahuje pouze základní funkce a vyžaduje IPv4 pro své fungování
(DNS), takže pro zkoušení pokročilých funkcí nebo hromadné nasazení není vhodná. Počítač s
podporovanou verzí Windows by však součástí testovací sítě měl co nejdříve být, už z důvodu
sledování vývoje a zlepšování podpory IPv6 v nových verzích nejrozšířenějšího operačního systému
pro koncové stanice. Rozmanitost testovaných platforem je velmi důležitá.
Z hlediska hardware a infrastruktury by bylo vhodné vyčlenění zvláštních počítačů pro tyto
testovací účely (stačí starších nebo málo výkonných) a trvalé zřízení této testovací sítě, která by byla
stále vylepšována podle aktuálního stavu vývoje implementací. Společně s růstem testovací sítě by
bylo vhodné zkoušet i zcela nové služby, například mobilitu (přechod mezi podsítěmi), přenos služeb
se zaručenou kvalitou a různé mechanismy zabezpečení na třetí vrstvě. Tyto vlastnosti jsem nyní
netestoval z důvodu příliš jednoduché topologie sítě a absence podpory těchto funkcí na uzlech
s operačním systémem Solaris.
Trvalé zřízení IPv6 sítě by mělo zahrnovat také duální implementace protokolu na servery, které
poskytují služby do vnějšího Internetu, případně služby, které musí využívat většina uzlů vnitřní sítě
(DNS, web, http cache, SMTP, news, DHCP apod.). Nemuselo by jít nutně o instalaci nového
fyzického síťového rozhraní, ale například použití manuálně konfigurovaných tunelů přes IPv4 nebo
nativní připojení těchto uzlů k jednomu sdíleném IPv4/IPv6 přepínači, ke kterému by vedle IPv4
směrovače byl připojen i směrovač IPv6 paketů). Náklady na toto zdvojení by mohly být poměrně
malé (instalace IPv6 doplňků do operačního systému) a možnosti použití uzlů velké (absence nutnosti
instalovat další dedikované IPv6 servery s těmito službami, integrace a společná konfigurace,
usnadnění správy, možnost částečně regulovat používanou verzi IP, dvojí použití jedněch dat a
podobně).
Měla by tak být k dispozici aktuální IPv6 síť připravená na to, až v budoucnu přijde na VŠE
požadavek na IPv6 konektivitu nebo na nějakou ze služeb nového protokolu.
strana 81
10.
Nástin ostrého přechodu v síti VŠE
10.1. O této kapitole
Obsahem této kapitoly je nástin aplikace přechodových mechanismů zmíněných v teoretické
části na síť Vysoké školy ekonomické v Praze. Pokusil jsem se shrnout motivy, které by k přechodu
mohly vést, některé důvody proti a odhad nasazených postupů.
10.2. Popis sítě
Počítačová síť Vysoké školy ekonomické je jedním ze základních komunikačních kanálů a
médiem pro poskytování informačních služeb. Mezi její nejdůležitější služby patří používání
elektronické pošty a diskusních skupin zaměstnanci i studenty, poskytování informací z útvarů školy
(pomocí webového prostředí), knihovnické služby, poskytování souborových a tiskových služeb.
V poslední době se začíná rozbíhat i používání multimediálních aplikací (videokonference, vzdálená
výuka) a pokročilých forem sdílení kancelářských dat (groupware, workflow). Přes počítačovou síť je
provozován ekonomický a studijní informační systém školy a uživatelé mají možnost používat
počítačovou síť pro vybrané vlastní vývojové, výzkumné a výukové projekty.
Síť VŠE je rozčleněna do několika lokalit v Praze (Žižkov, Jižní město, Jarov, Štěpánská a
další) a v Jindřichově Hradci. Pražské lokality jsou propojeny pomocí společné akademické sítě
PASNET, do Jindřichova Hradce pak vede spoj sdružení CESNET. Významnou částí sítě VŠE je také
připojování individuálních počítačů studentů VŠE na kolejích (lokalita Jarov a později zřejmě i Jižní
město). Použitou přenosovou technologií na páteři v pražských lokalitách je ATM a Gigabitový
Ethernet, který je uvažován i delším výhledu. V lokálních sítích je použita kombinace sdíleného a
přepínaného Ethernetu, kaskádově od nejvyšší rychlosti po nejmenší. Ze síťových protokolů jsou
celoškolsky podporovány a směrovány IPv4 a IPX, v určitých částech sítě (např. laboratoře kateder)
lze najít i jiné technologie. Důležité je jak IPX (souborové servery a tiskárny systému Novell
Netware), tak i IP (všechny externí informační služby, Intranet, některé souborové archívy, přístup ke
vzdáleným systémům a další). U IPX se nicméně předpokládá jeho postupné opuštění a přechod na IP
(Novell je schopen fungovat i na protokolu IP, možná dojde i k nahrazení systémů Novell jinou
technologií).
10.3. Motivy přechodu
VŠE byla vždy v přední linii akademických institucí, které zaváděly elektronické síťové služby
(EARN, první IPv4 sítě apod.) a používaly je účelně pro svou práci. I když IPv6 není novinkou
takového rozsahu jako ty dřívější, nemusí být implementace IPv6 ponechána až do posledních fází
přechodu (kdy už budou všechny okolní sítě na IPv6 také). Naopak, může využít svého akademického
a nekomerčního charakteru a nabídnout svým uživatelům IPv6 konektivitu a služby již dříve.
Z výsledků získaných při počátečních fázích přechodu pak mohou čerpat i komerční instituce a
konzultační firmy. O služby, které se v akademickém provozu nejlépe osvědčí, pak budou mít zájem i
firmy a budou implementovány do produkčních systémů výrobních, obchodních a jiných podniků. To
vše bude v souladu s posláním školy jako vzdělávací a výzkumné instituce zaměřené na ekonomii a
ekonomiku.
Co může IPv6 přinést škole dobrého? VŠE bude moci lépe využívat svou infrastrukturu pro
poskytování služeb vzdáleného vyučování, v některých případech i na placené bázi. Bude moci
nabídnout svým zaměstnancům možnost zvýšené mobility (což ocení zejména ti, kteří úzce
spolupracují s praxí a externisté). Usnadní se možnost připojování individuálních uzlů (například na
kolejích nebo přenosných počítačů studentů), zejména díky lepší podpoře bezpečnosti a automatické
konfiguraci. Bude možné šířeji implementovat bezdrátové přístupové sítě – například v rámci jedné
lokality VŠE budou moci studenti přecházet mezi přednáškovými sály a být přitom stále připojeni
všemi svými přenosnými zařízeními (PDA, notebook, telefon). Ulehčí se migrace osob mezi
lokalitami VŠE díky snadné registraci jednoho zařízení v různých lokalitách a vznikne stálá
dostupnost dané osoby (služby) pod jednou adresou.
Nezanedbatelné usnadnění bude mít protokol při správě koncových stanic, kde se usnadní
automatické připojování a případné změny topologie sítě. Zlepší se bezpečnost a důvěryhodnost sítě
díky podpoře šifrování a autentizace, takže se usnadní hlídání důležitých síťových zdrojů proti zneužití
a citlivá data (přenosy studijní a ekonomické agendy školy) nebudou moci být odposlechnuta. Bude
strana 82
možno rutinně nasadit přenos hlasu po datové síti (například IP telefony přímo do kanceláří) a
integrovat telefonní služby.
Které okolnosti by mohly přechodu bránit? Přechodem na IPv6 ovšem může škola přijít o
možnost používání některých aplikací, které již nebudou autorem podporovány. Pokud půjde o
aplikace klíčové, bude pro ně nutno realizovat komplikovanější přechodový mechanismus (například
na bázi BIA) nebo bude nutno nákladně přejít na řešení zcela nové. Dodatečné náklady na přechod
jsou asi nejvýznamnější překážkou – řada IPv4 zařízení nebude v době přechodu po skončení
životnosti a bude je třeba upgradovat (pořídit jejich novou verzi), aby se prostředky do nich vložené
vrátily.
Rizikem je také dočasné rozdvojení jednolité sítě a například horší spolupráce po všech
protokolech mezi jednotlivými lokalitami. Síť je poměrně složitá a je třeba vždy dobře předem
promyslet všechny návaznosti na okolí. Přechod VŠE na IPv6 bude mít smysl samozřejmě
v okamžiku, pokud na tento nový protokol začnou přecházet i ostatní sítě, zejména akademických
institucí v ČR a i v zahraničí (čímž se mj. usnadní mezinárodní spolupráce). Musí být také k dispozici
dostatečně stabilní implementace základních přechodových mechanismů (např. ISATAP), které by
měly být standardizovány a ověřeny provozem v laboratorních sítích. To zatím není u většiny splněno.
10.4.
Nástin postupu přechodu
10.4.1. Počátek
Začátek přechodu sítě na IPv6 odhaduji až ve velmi vzdáleném čase. Na VŠE zcela určitě ještě
dojde ke změně struktury a topologie IPv4 sítě, zejména k rozšíření přenosových kapacit páteřní sítě a
nasazení nových směrovačů do lokalit, kde zatím zařízení třetí vrstvy nejsou (Jarov, Jižní Město). Při
uvažování o přechodu je proto třeba vycházet z budoucího stavu. Podrobnější schéma sítě je možné
nalézt například v [4].
První, spíše přípravnou fází přechodu, by mohlo být zřízení IPv4 tunelu do akademické sítě
CESNET, o které předpokládám, že bude akademickým poskytovatelem internetového připojení i
v budoucnu. Již nyní existuje možnost připojit se jejímu k výzkumnému projektu IPv6. IPv6 tunel
může končit na směrovači v malé síti určené pro testování IPv6 implementací a aplikací pro různé
operační systémy. Tato síť by neměla být určena pro běžný provoz ani přístup uživatelů, spoje by
měly být IPv6 nativní. Předpokládal bych nasazení menšího směrovače Cisco pro testování operačního
systému IOS této firmy, a několik malých podsítí s uzly s operačními systémy Windows (nejspíše
2000 a XP), Linux, FreeBSD, Solaris a případně i Novell (ale ten jen v případě, že bude rozhodnuto o
jeho další perspektivě na VŠE). Sestavení a použití takové laboratorní sítě jsem naznačil v předchozí
kapitole.
10.4.2. Pro první uživatele
Ostré zavádění pro první servery a prvním uživatelům bude vycházet ze získaných zkušeností
z této laboratorní sítě. Konektivita přes nový protokol může být zajištěna nativně přes Ethernet nebo
automatickým tunelováním do laboratorní sítě, odkud bude provoz ven směřovat dříve vytvořeným
tunelem. Analogickým způsobem bude možné připojit některé vybrané koncové stanice, podmínkou je
ovšem nasazení přechodové technologie ISATAP, případně manuálních tunelů na koncových duálních
uzlech. Rozhodujícím faktorem bude existence použitelných aplikací pro IPv6 sítě.
Zajímavou otázkou bude připojení DNS serverů, které budou muset zůstat na IPv4 až do doby,
než přejdou na nový protokol také doménové servery nejvyšší úrovně domény .cz. Pro dotazy
z nových uzlů v lokální síti mohou mít tyto servery implementován i IPv6 protokol. Osobně bych
velmi rád viděl připojení všech serverů, které poskytují externí služby, do obou sítí, například
způsobem zmíněným v závěru předchozí kapitoly o dalším rozvoji testovací sítě. Stejným způsobem je
potřeba zajistit připojení důležitých interních serverů a služeb (DHCP servery, Netware systémy),
protože je budou nejspíše používat uzly z obou sítí.
Síť bude založena stále na IPv4 včetně hlavních aktivních prvků (směrovačů). Pokud bude
připojování duálních uzlů úspěšné (a příslušná část provozu přes IPv6 skutečně půjde), bude možné
začít připojovat i pouze IPv6 uzly (v IPv4 síti). Pro umožnění jejich komunikace s ostatním síťovým
světem bude potřeba zprovoznit (nejspíše v laboratorní síti, ale možno i kdekoliv jinde) překladovou
bránu, která bude IPv6 pakety transformovat na IPv4 provoz (nejspíše na bázi NAT/PT). Půjde o
strana 83
mírně „krkolomné“ řešení, protože z jedné strany brány bude IPv4 Internet a z druhé strany brány
také, nicméně z vnitřní strany bude použit jen pro účely tunelování (např. ISATAP) IPv6 paketů.
Může tak jít o jednoduché IPv4 zařízení s jedním rozhraním, které oddělí vnitřní a vnější překládaný
IPv6 provoz, případně na něm bude zřízen IPv6 tunel do zkušební sítě. Použití brány bude v nějaké
formě nezbytné.
10.4.3. Přechod celých podsítí
Jak jsem již naznačil, v síti VŠE budou přecházet jen některé uzly v různých IPv4 podsítích.
Tento stav je možné ponechat po nějakou dobu, dokud bude administrace dvojí infrastruktury
zvládnutelná. Z hlediska správy je samozřejmě lepší přecházet na nový protokol po větších částech
sítě. Pokud bude v nějaké části sítě dostatek IPv6 uzlů (které budou provozuschopné – budou pro ně
existovat síťové aplikace), bude se moci začít uvažovat o vypuštění IPv4 vrstvy a nahrazení zbylých
IPv4 počítačů IPv6 implementacemi.
To by znamenalo instalaci duálního protokolu na místně příslušný směrovač tak, aby některá
rozhraní mohl mít na IPv4 a jiná na IPv6. S vnějším IPv6 světem se bude dorozumívat přes ISATAP
do laboratorní sítě nebo manuálně nakonfigurovaným tunelem. Pokud bude takovýchto IPv6 ostrovů
více, mohou se jejich hraniční směrovače mezi sebou dorozumívat pomocí 6to4 automatických tunelů
a výstupní bod do externího IPv6 Internetu bude opět v laboratorní síti. Podmínkou je existence
síťových prvků druhé vrstvy, kterým nevadí absence IPv4 konektivity (např. jejich administrační
rozhraní je dosažitelné i po IPv6)
Jakmile se dostane implementace IPv6 na některý ze směrovačů, je možné uvažovat o přenesení
koncového bodu tunelu do Internetu ze zkušební sítě na něj. Testovací síť tak ztratí na své důležitosti
jako tranzitní a stane se z ní jen další nativní IPv6 ostrov. Směrovač v ní do té doby použitý bude
možné přesunout jinam.
Pokud bude vývoj okolních sítí podobný síti VŠE (například v rámci pražské akademické sítě
PASNET dojde také ke stavbě IPv6 ostrovů), bude možné využít služeb automatického tunelování
6to4 mezi těmito sítěmi (pokud budou mít tyto sítě přidělený celosvětový 6to4 prefix začínající
2002::/16). Automatické tunely budou vytvářeny mezi směrovači na okrajích těchto sítí. Bude li
koncept 6to4 celosvětově životaschopný, nic by nemělo bránit postupnému opouštění manuálně
konfigurovaných tunelů a používání tunel serverů. Konektivita by mohla být zajišťována automaticky
po IPv4 infrastruktuře do nejbližšího dalšího propojovacího 6to4 bodu a manuální tunel by byl jen
záložním spojením.
10.4.4. Přechod celých lokalit
Postupem času a hlavně díky dostupnosti IPv6 aplikací by mohly některé lokality přejít na IPv6
zcela. Tím by mohlo dojít i převedení některých páteřních spojů (např. spojení lokalit) na nativní IPv6,
zrušení IPv4 implementace na dotčeném směrovači a celkovému zvětšení ostrova s IPv6 uzly.
Nicméně někde poblíž výstupního místa ze sítě by stále musela existovat překladová IPv4
brána, v pozdější fázi přechodu už se dvěma síťovými rozhraními – s jedním do zbytku IPv4 sítě a
s druhým již přímo nativním IPv6. Vzhledem k nezávislosti lokalit by bylo vhodné, aby takováto
překladová brána existovala v každé z nich, například párově k výstupnímu směrovači každé lokality a
úplně nejlépe integrovaná v něm.
Vzhledem k nákladnosti pořízení profesionálních směrovačů bych předpokládal v každé lokalitě
nasazení jen jednoho výstupního směrovače, který bude schopen komunikovat po obou protokolech a
zároveň vykonávat práci překladové brány. Variantně by mohl být nasazen vedle IPv4 směrovače jako
IPv6 směrovač běžný počítač s nainstalovanou stabilní implementací směrovacího software (např.
FreeBSD/KAME). Tím by se mohl ponechat stávající IPv4 směrovač delší dobu beze změny –
náklady na nový software by se přesunuly na pozdější dobu a výpočetně by se oba protokoly oddělily,
což by vedlo k větší odolnosti přechodového řešení.
K vytvoření velké IPv6 sítě v rámci VŠE ve více lokalitách dojde zřejmě až ke konci přechodu,
a to zřejmě nejdříve v relaci Žižkov-Jarov (mimo PASNET). Pokud bude v metropolitní síti PASNET
k dispozici duální IP implementace (a já očekávám že zde bude k dispozici velmi časně), nemělo by
být problémem ani připojení dalších lokalit (Jižní Město, Štěpánská) přímo přes IPv6. Přechod
páteřních sítí bude až závěrečnou záležitostí – koncový uživatel změny nepozná a rozdíl bude v jen
strana 84
podílu přenášených režijních dat (tunelů). Dojde k němu až v okamžiku, kdy se správci budou většiny
svých IPv4 prvků zbavovat pro jejich nepotřebnost a zjednodušovat si práci s údržbou infrastruktury.
Některé služby by měly zůstat duální nebo s blízkostí překladové brány až do konce přechodu,
zejména DNS, poštovní a webový server (externí služby), aby byly dostupné v případě výpadku jedné
z implementací. VŠE tedy bude muset mít jak IPv6, tak i IPv4 přípojku po celou dobu přechodu.
Analogicky se tedy bude muset chovat i poskytovatel připojení VŠE - CESNET jako poskytovatel IP
konektivity a PASNET jako poskytovatel části infrastruktury. Očekávám, že v první fázi bude
existovat již zmíněný IPv6 tunel nad IPv4 infrastrukturou, poté může existovat v PASNETu a
CESNETu duální implementace a nakonec půjde o IPv4 tunely nad IPv6 infrastrukturou.
10.4.5. Dokončení
Od vzniku prvního IPv6 uzlu, který nebude původní protokol znát, bude muset existovat
překladová brána mezi IPv4 a IPv6 světem – nejdříve postupně v každé významnější lokalitě, odkud
půjde směrovat IPv4 a IPv6 provoz, s pozdějším propojováním IPv6 sítí bude stačit jejich počet menší
(měly by být integrované s hraničním duálním směrovačem). V závěrečné fázi přechodu by mohla
stačit jedna překladová brána pro celý PASNET, resp. CESNET. Tyto brány budou muset existovat až
do úplného zmizení všech IPv4 serverových služeb v Internetu.
Po celou dobu přechodu budou muset zůstat bez narušení další síťové služby a protokoly, které
mají zůstat nedotčeny (např. IPX/SPX, pokud v té době ještě bude na VŠE používán) a k výpadkům
dotčených služeb by mělo docházet jen po čas nutné údržby, implementace a instalace do síťových
prvků – přechodové mechanismy toto umožňují. IPv6 služby se by měly být vytvářeny podle
aktuálních možností organizace, sítě a jejího správce jako negarantovaná služba vedle stále běžícího
IPv4 a v případě ověření stability v praxi by měly být předány uživatelům do trvalého užívání. Nutné
výpadky je třeba plánovat do nevytížených časů (víkendy, přestávky mezi semestry, prázdniny apod.).
10.4.6. Časový plán
Časový interval je v tuto chvíli velmi nejistý. Orientačně by mohlo být
- Testovací síť a upgrade DNS serveru:
ihned
- Duální protokol na vybrané koncové stanice mimo testovací síť:
cca 0,5-1 rok poté
- Nativní IPv6 protokol na vybrané stanice + instalace překladačů (NAT/PT): cca 1 rok poté
- Vytváření nativních IPv6 podsítí, vytváření duálních IPv6 směrovačů:
cca 2 roky poté
- Automatické tunelování 6to4 mezi vnitřními a vnějšími sítěmi:
cca 1 rok poté
- Přechod celé lokality, případně páteřního spoje, tvorba IPv4 tunelu:
cca 3 roky poté
- Dokončování odstraňování IPv4 infrastruktury v lokální síti:
cca 3 roky poté
- Konec přechodu, odstraňování překladových bran:
cca 5 let poté
Celková doba se tedy blíží již výše uvedeným 15 letům. Opět bych chtěl připomenout, že
odhady jsou velmi nepřesné a 15 let je v ICT příliš dlouhá doba na to, aby vše zůstalo stejné. Mnoho
vnitřních a vnějších podnětů může přechod ovlivnit. Nejspíše bude potřeba připojit nové útvary školy,
bude potřeba zajistit nové služby s IPv6 přímo nesouvisející, změní se topologie sítě, informační
potřeby školy, představa o zajištění pracovníků a studentů výpočetní technikou (např. bezdrátové sítě)
a podobně.
Postup sestavený v této kapitole je pouze základním nástinem a hrubou představou, po kterých
krocích a v reakci na které vnější impulsy by se mohlo přecházet. Pořadí i samotný způsob se může
změnit na základě aktuálních potřeb VŠE, které nyní nejsem schopen odhadnout. Rozmyšlení
přechodového plánu pro skutečné použití by také mělo být mnohem detailnější a mělo by brát v úvahu
i faktory, které jsem nyní zanedbal (dokončení standardizace, finance a ekonomickou situaci školy,
lidské zdroje VŠE, postoj CESNETu, možnosti připojených uživatelů – např. na kolejích a další). Vše
uvedené samozřejmě platí za předpokladu, že přechod na IPv6 bude celosvětový a přecházet budou i
ostatní sítě.
strana 85
11.
Shrnutí obsahu práce
11.1. O této kapitole
Tato kapitola celkovým zhodnocením celé diplomové práce. Shrnuji v ní v několika kratších
sekcích její celý obsah, teoretickou a praktickou část. Důraz je kladen na výsledky, ke kterým jsem
dospěl a můj vlastní přínos k řešené problematice. Závěrem se zamýšlím nad využitelností zjištěných
výsledků a náměty na další řešení oblasti přechodu na nový internetový protokol.
11.2.
Shrnutí výsledků z teoretické části
11.2.1. Proč vznikl IPv6
Návrhy nových protokolů na bázi IP začaly vznikat na přelomu osmdesátých a devadesátých let
minulého století jako vylepšené alternativy k protokolu IPv4. Hlavním důvodem bylo přidat
k původnímu IP další doplňkové funkce a zvětšit adresní rozsah ze stávajících 32 bitů. V průběhu 90.
let v souvislosti s exponenciálním nárůstem uživatelů Internetu začaly stále více na povrch vystupovat
problémy původní verze protokolu a nějaké řešení bylo a je stále naléhavější. Mezi nejvýznamnější
potíže patří nedostatek volných adres pro přidělení novým uzlům, rostoucí počet záznamů ve
směrovacích tabulkách páteřních směrovačů, slabá podpora bezpečnosti, mulitcastových přenosů,
mobilních zařízení a přenosových služeb se zajištěnou kvalitou.
Každý z problémů lze řešit více způsoby, obecně jsou řešení dvě – jako doplněk ke stávajícímu
řešení nebo zcela nově, od čistého stolu. Jednodušší řešení je funkce doplňovat, tento způsob však má
jistá omezení a není možné vždy dosáhnout takové kvality a robustnosti, jako u kompletního
přepracování protokolu. To je zase náročnější na implementaci a zavedení po světě – zpětnou
kompatibilitu lze zachovat jen obtížně a zavedení na všech místech najednou je skoro nemožné.
V současné době (od roku 1998 do 2002) jsou problémy IPv4 řešeny doplňkovými metodami
s paralelním vedlejším vývojem nového protokolu jako zcela nového řešení. Na nedostatek IPv4 adres
se podařilo nasadit metody beztřídních sítí (CIDR) a překladu adres (NAT), kvalitu služeb se snaží
řešit rezervační protokoly (RSVP) a Differentiated & Integrated Services, bezpečnost IPSec, mobilitu
Mobile IP a multicast speciální směrovací protokoly (PIM) se speciálními rozsahy IPv4 adres.
Nejde ovšem o řešení ideální – řada z nich není v IPv4 povinná, takže je není možné využít
v každém místě a po celé přenosové trase (což je například u kvality přenosu nevýhoda podstatná),
takže jejich implementace a nasazení vyžaduje velké úsilí a je pak k dispozici jen některým uzlům.
Překladu adres (NAT) zase omezuje vzájemnou konektivitu libovolných dvou uzlů v Internetu,
porušuje princip oddělených vrstev a ruší bezstavovost IP, takže není použitelný univerzálně a je třeba
jej speciálně konfigurovat. NAT je asi největším trnem v oku zastáncům původního „čistého“
Internetu a velkým argumentem pro úplně nové řešení – nelze donekonečna doplňovat nestandardní
postupy a obcházet systémové nedostatky záplatami, na které je potřeba dávat pozor a tvoří další (sice
menší) problémy. S očekávaným nárůstem počtu připojených uzlů (pokračování exponenciálního
trendu zejména díky drobným a mobilním zařízením) by již NAT zřejmě nestačil adresně, ani svými
možnostmi služeb (dvě zařízení za překladovými bránami by se nedomluvila, což by omezilo
například telefonování, využití herních a dalších výměnných peer-to-peer aplikací).
Stále více faktorů se tedy přidává při volbě o řešeních na misku vah novému protokolu
s integrovanými řešeními. Rozsah adresního prostoru lze koncepčně nejsprávněji změnit jen novým
rozvržením místa v hlavičce, čímž ovšem nebude zachována zpětná kompatibilita se stávajícím
Internetem. A pokud už je nutné přecházet na něco nového, proč už do toho rovnou nezahrnout i další
požadované vlastnosti. Z těchto idejí vychází i tvůrci nového řešení, které posléze vykrystalizovalo do
formy IPv6.
Dle mého názoru je volba zcela nového řešení bez respektování předchozích nedokonalostí
správná. Nějakou dobu by sice bylo možné (a asi i bude nutné) nastavovat funkčnost IPv4 pomocí
doplňků a nesystémových řešení, ovšem nelze takto vydržet věčně. V nějakém časové okamžiku by se
stejně muselo k důslednějšímu řešení přistoupit – ne nutně k IPv6, ale k nějakému určitě. A čím dříve
bude takový standard včetně mechanismu přechodu navržen, tím lépe.
strana 86
11.2.2. Nejvýznamnější vlastnosti
IPv6 řeší výše uvedené problémy v dlouhodobém výhledu tak, aby mělo řešení šanci na dlouhý
život. Rozsah adres byl zvýšen na 128 bitů, což by bez rozdělení do podsítí znamenalo možnost
připojit až téměř neuvěřitelných 3,4*10^38 koncových uzlů a nikdy už by nemělo dojít k jejich
nedostatku. Byly specifikovány mechanismy pro jejich členění, přidělování poskytovatelům různé
úrovně a agregaci tak, aby byla práce se směrovacími informacemi co nejjednodušší. Byly stanoveny
nové druhy adres (unicast, anycast, multicast), které lépe odpovídají nejčastějším požadavkům na druh
směrování v Internetu. Byly vyčleněny tři základní skupiny adres dle rozsahu a platnosti – globální
(platné po celém světě), lokalitně místní (platné v rámci jedné organizace nebo její části) a spojově
místní (platné na daném fyzickém médiu). Adresa se nově zapisuje jako osm čtveřic šestnáctkových
čísel oddělených dvojtečkami postupně od nejobecnějšího prefixu až po identifikaci síťového rozhraní
na konci (tedy napřklad 7812:AB36:CD45:EF96:1234:DCBA:5678:EFGH). Směrování bude beztřídní,
pouze na základě aktuální masky podsítě (délky prefixu) daného spoje.
Pro usnadnění konfigurace síťových uzlů byl v protokolu navržen mechanismus automatického
objevování sousedů a bezstavové konfigurace, která umožňuje uzlu sestavit si nutné komunikační
informace z ohlášení směrovacích informací po síti, případně na vlastní žádost od směrovače.
Zachována zůstala i možnost konfigurace pomocí vyhrazeného serveru na bázi nové verze DHCP.
Všem těmto mechanismům napomáhá vylepšený řídící protokol ICMPv6.
Paket má v nové verzi hlavičku pevné délky. Doplňující informace k jednotlivým paketům je
možné uvést v doplňujících hlavičkách, které se řetězí mezi základní hlavičku a přenášená data paketu
v pořadí důležitosti pro mezilehlé směrovače. Mezi doplňkové hlavičky patří směrovací (slouží
k podpoře směrování přes vybrané mezilehlé uzly), autentizační, šifrovací (k podpoře bezpečnosti),
fragmentovací (pro sestavování rozdělených paketů) a speciální pro předávání parametrů směrovačům
po cestě.
Pro implementaci bezpečnosti byl přidán v IPv6 mechanismus IPSec, známým už z IPv4,
nicméně v novém protokolu musí být povinně. Má dvě základní metody použití – autentizace (ověřuje
odesílatele a integritu paketu, nicméně nechrání proti odposlechu dat) a šifrování (převádí data do
formy čitelné pouze oprávněným příjemcem).
Pro zajištění přenosových služeb se zajištěnou kvalitou byla přidána povinnost implementovat
Differentiated a Integrated Services, opět již navržených pro prostředí IPv4. Jde o možnost dělit
pakety na směrovačích do různě prioritních front a tím zajistit některým službám rychlejší zpracování
na úkor jiných. Ve spolupráci s rezervací přenosového pásma na přenosové cestě a značkováním
datových toků (například příslušejícímu k jednomu multimediálnímu přenosu) by mělo být možné
garantovat zajištěné služby i přímo mezi koncovými uzly, ať jsou kdekoliv. Garantované služby by se
tak nemusely zajišťovat s pomocí zařízení 2. vrstvy (např. ATM) nebo „silově“ fyzickým zvyšováním
přenosových kapacit linek.
Mobilita přináší do IP světa možnost pro libovolný uzel přesouvat se mezi různými podsítěmi
bez přerušení aktuálních přenosů a dostupnost pod jedinou a stálou IP adresou. V cizích sítích musí
pro zajištění správného směrování dostat cestovatel dočasně přidělenu cestovní adresu, nicméně jeho
domácí je stále platná. Základními prvky systému jsou domácí agent (home agent, HA), který má
přehled o cestujících uzlech své sítě, a mobilní agent (mobile agent, MA), což je vlastní cestovatel.
Ten se s dočasně přidělenou cestovní adresou ohlásí domácímu agentu, který v domácí síti hlídá
příchozí pakety na domácí adresu odcestovalého uzlu a přesměrovává je na jeho aktuální cestovní
adresu. Mobilní agent ji pak sdělí původnímu odesílateli, který si ji aktualizuje a dále s cestujícím
uzlem komunikuje přímo. Mobilní uzel se může přesunout mezi sítěmi různých poskytovatelů i během
existujícího přenosu, který by měl v pořádku pokračovat (vytvoří se další aktualizace vazby).
DNS bude vzhledem ke složitosti IPv6 adres povinnou službou. Stávající hierarchický systém
domén zůstal zachován a každé jméno bude moci mít buď IPv4, IPv6 nebo obě adresy současně (A
záznam, AAAA (A6) záznam). Reverzní dotazy PTR („znám číselnou adresu a chci znát jméno“)
budou řešeny pomoci dotazů do domény IP6.ARPA, analogicky jako v IPv4 funguje doména INADDR.ARPA.
Nové vlastnosti jsou velmi lákavé a řeší mnoho současných neduhů. Dle mého názoru byly jako
nové přidány správně jen ty funkce, které potenciálně bude využívat většina aplikací, aniž by došlo
k neodpovídajícímu nárůstu náročnosti implementace a zpracování na směrovačích. Jistě, protokol je o
něco bohatší a složitější co do funkčnosti, nicméně při návrhu byla uvažována i optimalizace
strana 87
z hlediska rychlosti zpracování paketu a pro dnešní výkonné systémy by neměl vznikat větší problém.
Navíc bude možno zjednodušit práci tvůrcům aplikací, což urychlí jejich vývoj. Pokud budou všechny
implementace důsledné v dodržování standardů, může zde vzniknout velmi mocná síťová
infrastruktura.
11.2.3. Soužití s IPv4 a přechod na novou verzi
Protože není možné na nový protokol přejít najednou všude na světě, byla stanovena řada
mechanismů, které umožní oběma protokolům existovat po určitý čas společně při zajištění vzájemné
konektivity. Základem je duální protokol, neboli implementace obou verzí společně na jediném uzlu.
Aplikace pak využije ten protokolový zásobník, který umí, a ten pak komunikuje s dalšími síťovými
zařízeními (na jednom fyzickém spoji může existovat i IPv4 a IPv6 síť bez problémů dohromady).
Vzhledem k vyčerpávání IP adres však takto nepůjde zajistit celý přechod. Dalšími způsoby
jsou různé varianty tunelování paketů – propojování dvou oddělených ostrovů sítí, které umí
komunikovat stejným protokolem, ale mezi nimi leží infrastruktura opačné verze. Ta se v takovém
případě použije jako pseudo-spojová vrstva (nakonfiguruje se v ní začátek a konec tunelu a cesta mezi
nimi je pro „ostrovní“ protokol neviditelná, pakety jsou zapouzdřeny). Existují i řešení pro současné
připojení IPv4 a IPv6 uzlů v jedné lokální síti s jedním směrovačem, kde dochází k automatickému
tunelování po IPv4 infrastruktuře, aniž by bylo nutno na koncových uzlech implementovat duální
protokol.
Dalším způsobem komunikace obou světů je nasazení překladových technologií. Může jít o
různé automatické překladače (speciálně vyhrazená část IPv6 adresy se použije jako IPv4 adresa, na
kterou se paket směruje) nebo o vyhrazené brány, které mají rozhraní jak do IPv4, tak do IPv6 sítě a
které udržují asociace mezi IPv4 a IPv6 adresami. Speciálním případem překladače je existence
programátorského rozhraní (API) se „dvěma tvářemi“ - BIA, kde se rozhraní pro aplikace tváří jako
jedna verze a pro síťové médium jako druhá verze protokolu. Mezi nimi dochází v koncovém uzlu
k transformaci protokolových struktur z jedné verze do druhé. Překladové mechanismy se týkají jak
IP, tak i řídícího protokolu ICMP.
Při nasazení těchto mechanismů může dojít k částečnému omezení konektivity (aby vůbec bylo
možné se dorozumět), případně k dalším nepředpokládaným problémům (výkonnost, stabilita, nutné
aplikační brány). Z určitého pohledu se může zdát, že problémy z IPv4 (NAT, overhead tunelovacích
mechanismů) byly přeneseny i do nové verze a že se tedy mnoho nezlepší. Ovšem není tomu tak – jde
jen o dočasné řešení (vůbec by nemuselo být, pokud by šlo přejít na IPv6 skokově) a bude použito dle
aktuální potřeby a stavu přechodu v dané síti. Mým názorem je, že přechodové mechanismy byly
navrženy dobře a v dostatečné rozmanitosti (každý správce si vybere ty, které jeho síti „sedí“ nejlépe),
aby splnily cíl dlouhé koexistence obou verzí, kterému se Internet bezesporu nevyhne.
11.2.4. Implementace a použití ve světě dnes
Dnešní stav použití a implementací by u někoho mohl vyvolat skepsi z malé a nekvalitní
podpory výrobci a velmi okrajového použití protokolu. Současný stav skutečně není situací, ve které
by mohla začít masová implementace nové verze a hromadné komerční využívání služeb protokolu.
Nicméně jde o velmi ranou fázi, kdy se implementace pro jednotlivé operační systémy a síťové prvky
teprve tvoří a odlaďují a provoz má charakter laboratorního a zkušebního. Je patrný stálý pokrok při
vývoji a zavádění nových funkcí na další platformy a při rozšiřování sítí, kde je IPv6 konektivita
dostupná i koncovým uživatelům.
Z operačních systémů mají nejkvalitnější podporu BSD unixy (open-sourcový projekt KAME),
ostatní unixové platformy (mj. Solaris, Linux, AIX, HP-UX a další) jsou mírně pozadu - chybí některé
funkce nebo nejsou stabilní. Nicméně díky otevřenosti projektu KAME lze přenést některé funkce a
aplikace i na tyto platformy a rozběhnout zkušební duální provoz. Na platformě Windows podporuje
firma Microsoft základními funkcemi systémy Windows 2000 a Windows XP. O nativní podpoře
Windows95/98/ME se neuvažuje, zde je třeba využít produkty dalších stran (např. Trumpet Winsock).
Na směrovačích uvažuje o podpoře většina výrobců, nicméně jde o velmi ranou fázi podpory.
Asi nejdále je firma Ericsson/Telebit, z velkých výrobců začíná s podporou Nortel Networks a plán
vývoje nových verzí má i Cisco Systems, který víceméně dodržuje (od verze 12.2.T je IPv6
podporován oficiálně). Implementace nových funkcí (mobilita aj.) nebo komplikovanějších
strana 88
směrovacích protokolů je zatím dobře rozvinutá jen v KAME, u ostatních platforem je třeba přijmout
určité omezení funkčnosti. Nicméně vývoj postupuje stále dál a jsou vydávány nové verze.
Podpora aplikacemi je v současné době pochopitelně velmi slabá, protože mimo laboratorní sítě
po nich není poptávka. Úprava aplikací na nový protokol je součástí už zmíněného projektu KAME
(Apache, BIND, postfix, squid, sendmail a jiné), tvůrci některých aplikací berou přizpůsobení svého
produktu na verzi 6 jako prestižní záležitost (Mozilla, OpenSSH), takže lze s určitými omezeními
sestavit i použitelnou pracovní stanici (jejíž funkčnost by zahrnovala surfování po Internetu, vzdálený
přístup k jiným systémům, posílání a příjem pošty a stahování souborů). Na běžné kancelářské použití
v podniku ovšem nejsou aplikace zatím připraveny, jejich použití je spíše testovací.
IPv6 je dnes záležitostí pokusných a akademických sítí (např. 6BONE, 6NET, Internet2/Abilene
v ČR pak CESNET). Přidělování provozních rozsahů IPv6 sítí autoritami Internetu (např. RIPE NCC)
již sice funguje, nicméně komerční poskytování nemá zdaleka globální charakter. Nativní připojení
jsou spíše ojedinělá, obvyklejším způsobem připojování dalších IPv6 uzlů jsou nějaké formy
tunelování. Tak se mohou do IPv6 sítě připojit zdarma i koncoví uživatelé (pomocí konfiguračních a
tunelovacích serverů). Podpora IPv6 ze strany větších světových poskytovatelů je postupně
ohlašována a snad bude v budoucích letech i naplňována.
Dnešní stav není dle mého názoru příliš podstatný pro určení budoucího úspěchu IPv6. Důležitý
je vývoj v porovnání s předchozím obdobím, který nabírá na rychlosti. Stále více rozhodujících
subjektů je o IPv6 jako o budoucím řešení přesvědčeno a implementuje ho ve stále kvalitnějších
provedeních. Nasazení do komerčního provozu může přijít až na těchto základech, které jsou nyní
testovány a nasazovány v laboratorních, akademických a jiných zkušebních sítích. Ke zkoušení IPv6
se může přidat prakticky kdokoli, kdo je vybaven znalostmi a potřebnou technikou. A čím více lidí
bude IPv6 znát a považovat jej za vhodné řešení, tím lépe se bude ve světě šířit a tím lépe se budou
řešit stávající problémy IPv4.
11.2.5. Ekonomické aspekty
Nový protokol se v praxi může uplatnit v mnoha oblastech. Mimo nahrazení IPv4 najdou nové
vlastnosti využití například v sítích mobilních telefonních operátorů (u nichž se v souvislosti s třetí
generací mobilních sítí čeká výrazný nárůst poptávky po datových přenosech a službách typu „alwayson“). Ti budou potřebovat nové adresy pro označování svých zařízení a částečně i podporu mobility
pro větší stabilitu datových přenosů.
S výhodou bude možno využívat multimediální aplikace s přenosem zvuku a obrazu v reálném
čase (díky podpoře kvality služby), například v zábavním průmyslu. Prostředí síťové vrstvy bude o
něco bezpečnější, což bude k dobru zejména elektronickému obchodu a ku podpoře tvorby virtuálních
privátních sítí přes veřejný Internet. Bude možno připojovat a přímo adresovat řadu drobných zařízení
(např. spotřební elektroniku, navigační systémy automobilů) a uspíšit konvergenci přenosových médií
(např. pro telefonní přenosy). Díky společné síťové infrastruktuře se usnadní práce dalším
zprostředkovatelům a poskytovatelům sofistikovanějších síťových služeb, například Application
Service Providerům (ASP).
Velké úsilí musí být věnováno hledání a implementaci různých přechodových mechanismů,
protože na nich bude velmi záležet, zda bude mít nový protokol úspěch. Je také potřeba dobře zvážit
předpoklady a motivy přechodu u jednotlivých subjektů, které mají se sítí co do činění (výrobci
síťových prvků, správci sítí, autoři aplikací, ISP, koncoví zákazníci). Motivy musí být silné,
problémem však je, že se u každého objeví v jiný čas, což komplikuje koordinaci. Mezi základní
motivy patří potřeba být připojen, komunikovat na standardní bázi s ostatními, využívat nové služby a
tržní příležitosti.
Pokud k přechodu na IPv6 skutečně dojde, bude to velkou událostí na telekomunikačním trhu,
vzdáleně porovnatelnou s přípravou přechodu na rok 2000 (problém Y2K), ale s mnoha odlišnostmi.
Přechod se neodehraje najednou a v nějakém pevně stanoveném čase, takže se všichni budou moci
včas připravit a neměly by vzniknout hrozivé vize (zejména v laických médiích) o možných
důsledcích přechodu. To by však nemělo vést k podcenění nutnosti se s novým protokolem včas
seznámit, jinak může dojít při přechodu k nepříjemným překvapením (jiná funkčnost než očekávaná,
náklady na akutní konzultační služby a podobně). Bude nutné aktualizovat operační systémy
směrovačů a koncových uzlů na aktuální podporované verze (pokud budou k dispozici).
strana 89
Přímý dopad nového protokolu na ekonomiku bude těžko odhadnutelný. Protokol usnadní
přístup k základním zdrojům ekonomiky (ke kterým informace také patří), takže se vliv projeví spíše
zprostředkovaně (úspory nákladů firmám, snadnější a rychlejší zavádění nových služeb, dostupnější
vzdělávání, uspíšení liberalizace telekomunikací a podobně). Protokol budou nejdříve zavádět
poskytovatelé internetového připojení (ISP) na základě tlaku o zákazníků (například mobilních
operátorů), kteří budou mít o nové služby a vlastnosti IPv6 zájem. Sami poskytovatelé se k přechodu
staví mírně rezervovaně – zahraniční jej slovně podporují a částečně i nabízí, domácí o něm nemluví a
odkládají jeho zavedení na delší budoucnost, až bude situace jasnější.
Tlak zákazníků bude záviset na jejich individuálních potřebách a podmínkách, které budou pro
každého jiné. Lze tedy očekávat sítě dlouhodobě spokojeně fungující na protokolu IPv4 a zároveň sítě,
které se bez IPv6 neobejdou. Od jistého okamžiku rozšíření IPv6 („většina okolních sítí už je po
přechodu“) bude výhodné přejít na novou verzi i původním sítím, takže závěr přechodu se dá očekávat
zrychlený.
Přechod a nasazení IPv6 má samozřejmě svá rizika a hrozby, kterým je nutno věnovat pozornost
(mj. není zpětná kompatibilita, není ověřen ve skutečném provozu, některé silné subjekty jej nemusí
chtít implementovat, nedostatek aplikací apod.). Pro úspěšné završení přechodu bude potřeba držet se
kritických faktorů úspěchu – rychlé implementace na nejpoužívanější platformy, rychlé řešení
problémů z provozu a propagace možností a výhod nového protokolu odpovědným osobám. Velkým
tahounem přechodu by mohla být právě tržní příležitost – například možnost s pomocí IPv6 zvýšit
významným způsobem výnosy, protože existuje velká skupina lidí ochotných platit za datové přenosy
v mobilních sítích.
11.2.6. Možný úspěch?
Úspěch zavedení protokolu se nedá v tuto chvíli příliš kvalifikovaně odhadnout. Jisté je, že
z různých alternativ k řešení problémů IPv4 je IPv6 zatím asi nejdál, jak z hlediska návrhu a
standardizace, tak z hlediska implementace a povědomí v mysli odborné veřejnosti. Zatím je spíše
snaha vyčkávat, až jak situace dopadne a jaké řešení se začne více rozvíjet. V tomto období zatím
dochází k aplikaci řešení na bázi IPv4, zřejmě však pouze dočasně.
Pokud se budou problémy (zejména s nedostatkem adres) dále prohlubovat, bude se muset ke
komplexnímu řešení přistoupit. Pak by mohl být pokrok dosažený v oblasti IPv6 velkou výhodou –
buď při jeho samotné implementaci nebo při dotváření jiného protokolu na jeho bázi. Osobně si
myslím, že se žádné „zázračné“ řešení na bázi IPv4 neobjeví a že jiné řešení než IPv6 na obzoru není,
takže by mohl být postupně zaveden. Další zdokonalování IPv6 už by přineslo jen malé výhody za
cenu komplikací a prodloužení řešení akutních problémů. Časový horizont je ovšem velkou neznámou
– odhady čisté doby přechodu překračují deset let.
11.3.
Shrnutí výsledků z praktické části
11.3.1. Současný stav registrace adres
Mimo teoretické pasáže úvahy jsem při zpracování práce zjistil a v rámci možností otestoval
aktuální stav různých záležitostí okolo IPv6. Důležitou otázkou je registrace rozsahů číselných adres,
kterou bude muset provést každý zájemce o připojení své sítě do IPv6. Možností přidělení prefixu je
několik, liší se typem organizace, které jsou adresy přiděleny a dostupným adresním prostorem
(délkou prefixu). Páteřní poskytovatelé internetové konektivity by měli dostávat krátké prefixy (velké
adresní prostory), protože budou adresovat velkou spoustu uzlů na hierarchicky nižších úrovních.
Přístupoví poskytovatelé a koncové sítě by měli naopak dostávat dlouhé prefixy (menší adresní
prostory), protože z nich budou adresovat pouze své sítě. Aby se adresami zbytečně neplýtvalo, byl
pro tyto účely vytvořen mechanismus postupného přidělování větších rozsahů, až když zájemce splní
dané podmínky a prokáže určitý stupeň (90 procent) zaplnění dříve přiděleného menšího adresního
prostoru.
Adresy bude tedy možné získat od poskytovatelů připojení nebo od registračních institucí typu
RIPE NCC, ARIN apod. (v současnosti zatím jediná možnost). Uvažuje se o přidělování /16 rozsahů
pro tranzitní a globální poskytovatele, /35 pro běžné přístupové poskytovatele a rozsahu /48 pro
koncové sítě. Při tomto dělení adresního prostoru se vychází z členění částí adresy na páteřní
agregační identifikátor (TLA), agregační identifikátor další úrovně (NLA) a agregační identifikátor
strana 90
koncové sítě (SLA). Agregační identifikátory (AID) slouží ke zjednodušování směrování a sdružování
cest ve směrovacích tabulkách směrovačů, které jsou vně popisované sítě. AID následují
bezprostředně za sebou v první části adresy a odpovídají subjektu (agregátorovi) dané úrovně.
Například do jednoho TLA o délce /16 lze agregovat všechny připojené sítě daného páteřního
poskytovatele, do jednoho NLA všechny připojené koncové sítě přístupového poskytovatele a
podobně. Čím se budeme v adrese posunovat dále doprava, tím detailnější informace o přiřazení
adresy získáme.
Každý se subjektů v připojovacím řetězci by měl mít dostatečný bitový prostor v adrese pro
členění svých sítí, agregátorům všech úrovní dohromady je vyhrazeno prvních 64 bitů adresy.
Vzhledem k častému používání EUI-64 identifikátoru pro označení konkrétního síťového rozhraní
v adrese se nepředpokládá členění prostoru za touto 64 bitovou hranicí (půjde výhradně o záležitost
místní sítě).
Pro VŠE by bylo vhodné zaregistrovat svůj rozsah u organizace CESNET, který bude nejspíše
poskytovatelem IPv6 konektivity pro akademické instituce i v budoucnu. CESNET je také zatím
jediným českých poskytovatelem, který má k dispozici definitivní provozní rozsah (2001:0718:/35),
který bude používat i do budoucna. Ostatní čeští poskytovatelé používají zatím pouze dočasné
testovací rozsahy, které organizace IANA vyhradila pro zkušební použití v síti 6bone (3FFE::/16).
Přidělení prefixu /48 z testovacího rozsahu sítě 6bone není problémem a dá se provést ihned, což jsem
také při testech ověřil.
11.3.2. Testování v praxi
Sestavením zkušební laboratorní sítě v prostorách VŠE ze třech uzlů jsem praxi ověřil funkčnost
implementace IPv6 v operačních systémech FreeBSD 4.5 a Solaris 8. Ověřované skutečnosti se týkaly
stability komunikace po novém protokolu, jednoduchosti konfigurace, dostupnosti základních
diagnostických nástrojů, možností statického a dynamického směrování, koexistence s IPv4
infrastrukturou, tvorby tunelů a funkčnosti některých síťových služeb a uživatelských aplikací.
Testování v některých ohledech i předčilo moje očekávání o současných možnostech IPv6,
protože laboratorní provoz, včetně připojení do externího IPv6 Internetu tunelem sítě Freenet6, byl až
na malé potíže bezproblémový. Při zkoušení jsem k vložení IPv6 adres do DNS použil primární
jmenný server školy, který tvořil jakýsi integrační prvek mezi oběma světy (v DNS byla základní zóna
ipv6.vse.cz a reverzní doména v IP6.ARPA, kterou se mi podařilo úspěšně delegovat od
poskytovatele připojení, takže DNS služby fungovaly pro VŠE celosvětově).
Základní aplikační služby jsou pro IPv6 již k dispozici (web, pošta, přenosy souborů, vzdálený
přístup apod.) a to jak v serverové, tak v klientské implementaci. Nejde vždy o programy masově
využívané, ale pro velké spektrum aktivit užitečné jsou. Myslím, že na testovaných platformách by
mohlo dojít k nasazení aplikací do provozu – většímu rozšíření ovšem brání převaha operačního
systému Windows starších verzí na koncových stanicích. V testování IPv6 by bylo vhodné dále
pokračovat rozšířením počtu uzlů a druhů platforem, trvalým zřízením testovací sítě, vytvořením IPv6
tunelu do sítě CESNET a případně i připojením do výzkumného projektu této instituce.
11.3.3. Budoucí přechod v síti VŠE
Pokud k přechodu na IPv6 dojde, budou muset být na VŠE provedeny jisté kroky a postupy, aby
byl přechod co nejméně problémový. Evoluce IPv6 bude muset být postupná, aby nevznikaly
najednou velké náklady a nedocházelo k výpadkům síťových služeb pro uživatele. Nejdříve se budou
připojovat pomocí tunelů k malým IPv6 sítím jednotlivé uzly podle aktuální potřeby. Pokud jich
v nějakém místě bude více, bude možné zřídit k nim nativní spoje, IPv6 směrovače a provozní
překladové brány do IPv4 světa.
Tím jak budou IPv6 ostrovy růst, se budou slučovat a postupně vytlačovat IPv4 prostředí.
V posledních fázích přechodu přejdou na IPv6 i páteřní spoje mezi lokalitami a budou existovat již
pouze ostrovy IPv4 sítí. Důležitým prvkem přechodu bude implementace dvojího protokolu na
důležitých serverech poskytujících externí služby (např. DNS, web, pošta, souborový archív) a interní
služby pro všechny vnitřní uzly (např. DHCP servery).
Konec přechodu bude doprovázen rušením IPv4 služeb v přístupových sítích (PASNET a
CESNET), nicméně časový horizont si netroufám blíže odhadnout – je velmi vzdálený, podle
některých odhadů 15 let od počátku přechodu. Za tak dlouhou dobu se může změnit mnohé.
strana 91
11.4. Zhodnocení využitelnosti dosažených výsledků
Předpoklady, postupy, výsledky a závěry této diplomové práce by mohly nalézt využití
v následujících oblastech:
- Uvedení čtenáře do problematiky současné a nové verze internetového protokolu, získání
základního přehledu o možnostech a schopnostech IPv6.
Zájemce o aktuální dění v oblasti rozlehlých sítí se z práce dozví, na jakých základech a
protokolech funguje celosvětová síť Internet. Dozví se o vývoji IP, vlastnostech současné verze, jejích
nedostatcích, a o řešení v podobě nové verze IP. Vlastnosti IPv6 a možnosti jeho nasazení do
internetového prostředí jsou v práci podrobně popsány. Obecně je tedy práce využitelná pro širší
osvětu o novém protokolu, který ještě není detailně známý. Z těchto důvodů obsahuje práce v úvodní
části také některé výkladové pasáže, které již může zkušenější čtenář znát.
- Jako referenční popis různých vlastností protokolu
Práce je souhrnem základních informací o konkrétních vlastnostech a mechanismech fungování
nového protokolu. Některé informace mají charakter výčtu nebo si je není možné po prvním přečtení
zapamatovat. V práci jsou proto popsány i základní informace spíše referenčního charakteru (tvary
různých druhů adres, konfigurační příkazy, záznamy v konfiguračních souborech, adresy webových
serverů, názvy aplikačních programů a podobně) a je možné si je v případě potřeby z textu oživit.
- Přehled aktuálního stavu implementací a sítí
V práci jsou uvedeny informace o protokolu IPv6 v celosvětových sítích k dubnu roku 2002.
Práce tak může sloužit jako zachycení stavu návrhu a zavádění IPv6 k tomuto datu, například pro
pozdější srovnání. Určitý čas po dopsání (než se skutečná situace příliš změní) může práce sloužit i
k nasměrování zájemců o připojení a podíl na výzkumu. Práce může poskytnout čtenáři určitou
představu, kdy se IPv6 může běžně objevit v operačních systémech a nabídkách komerčních
poskytovatelů internetového připojení.
- Uvažování o přínosech, nákladech a motivech přechodu na IPv6
V práci jsem uvedl i některé ekonomické aspekty přechodu na novou verzi. Mohou sloužit jako
další podpůrné materiály při úvahách o implementaci IPv6 do konkrétního prostředí, při tvorbě
strategických plánů, ekonomických rozvah o nové infrastruktuře, uvažování o nutných nákladech a
rizicích přechodu a podobně. Je také nastíněn vliv IPv6 na některé oblasti podnikání, kde může
protokol pomoci některým aktivitám.
- Budování vlastní zkušební sítě, připojování a adresace
Zkušenosti získané z testování malé IPv6 sítě by mohly sloužit dalším zájemcům o připojování
nebo budování IPv6 při jejich aktivitách. Mohou se vyhnout zdlouhavému zjišťování některých
konfiguračních detailů z mnoha zdrojů a urychlit počáteční fázi sestavování sítě a konfiguraci nutných
služeb (DNS apod.). Informace z testování pro ně mohou být východiskem pro další výzkum
sofistikovanějších vlastností protokolu.
- Uvažování o přechodech větších sítí
Kapitola nastiňující základní kroky přechodu sítě VŠE může být zobecněna jako vzor pro
přechod libovolné jiné větší IPv4 sítě, která se nachází v různých lokalitách a funguje na ní řada
důležitých služeb.
11.4.1. Další náměty na řešení problémové oblasti
Pokračování v testování složitějších a komplexnějších vlastností a topologií
Záležitosti kolem protokolu IPv6 jsou z určité části jen naznačené nebo hlouběji
neprozkoumané a bude třeba spoustu z teoreticky navržených postupů ověřit v praxi. Při konečném
nasazení nového protokolu půjde o velmi složitý systém s mnoha vazbami, jež je třeba předem
vyzkoušet. Řada mechanismů ještě není dokonale implementována a současný stav vědomostí a
nástrojů pro rutinní provoz rozhodně nestačí. Bude proto nutné provést ještě mnoho zkoušek a úprav
ve vytvářených mechanismech, než se stanou spolehlivými a výkonnými natolik, že je bude možno
použít kdekoliv v globální síti. Nutným dalším krokem by měla být tvorba zkušebních sítí v institucích
uvažujících o přechodu po celém světě, aby se všechny funkce vyzkoušely v prostředí co nejvíce
podobnému skutečnému budoucímu provozu.
- Propagace nového protokolu
IPv6 a jeho vlastnosti nejsou dle mého názoru mezi veřejností příliš známy. Ví se sice o
určitých problémech s nedostatkem IPv4 adres, nicméně k jejich řešení se používají technologie typu
-
strana 92
NAT, které se zdají být dostačující a navíc s určitým bezpečnostním přínosem. O IPv6 se uvažuje jako
o řešením pro situaci, až nebude vyhnutí a až budou všechny pomocné mechanismy v IPv4 vyčerpány.
Panuje přesvědčení, že přechod na IPv6 není zdaleka jasnou věcí a investice do jakýchkoliv aktivit
kolem něj mají velmi nejistou návratnost, takže jich mnoho vyvíjeno není.
Vhodné by proto bylo zesílit činnosti směřující k propagaci a vysvětlování výhod nového
protokolu, uvádět argumenty svědčící pro přechod a poukazovat na problémy, které by mohly nastat,
pokud by se nové řešení dlouhodobě odkládalo (zejména přetížení páteřních směrovačů a zastavení
možnosti růstu Internetu). Bude nutné rozšiřovat obecné povědomí o potřebě komplexně nového
protokolu řešící všechny problémy najednou, nikoliv jen dílčí oblasti. Propagaci by bylo dobré
provádět různým způsobem (odborné publikace, články v časopisech, semináře, informování a osvěta
odpovědných osob ve firmách a podobně).
- Řešení naznačených problémů, zvláště implementačních a přechodových
Jakým způsobem se dostat z IPv4 Internetu na IPv6 Internet s co nejmenšími obtíži? Tato
otázka je asi nejsložitějším problémem IPv6. Je navržena řada mechanismů, které mají přechod a
společnou existenci obou protokolů umožnit a usnadnit, nejasné je ovšem jejich nasazení do praxe a
spolupráce s existující infrastrukturou tak, aby nedocházelo k různým úzkým místům nebo omezení
dostupnosti služeb.
V této oblasti by síly měly být věnovány do tvorby a ověřování různých přechodových technik,
postupů a metodik. Ty by měly brát v úvahu všechny možné externí i interní faktory a vazby, které na
implementaci protokolu IPv6 mohou mít vliv. Jinak bude situace vypadat u poskytovatele připojení
k internetu, jinak bude situace vypadat ve velkém výrobním nebo obchodním podniku, jinak bude
situace vypadat u operátora mobilních telefonů a jinak bude vypadat v akademických institucích.
Vytvoření alespoň částečně univerzálního postupu a profesionální metody implementace IPv6
infrastruktury do provozního prostředí by celou přechodovou fázi mohlo výrazně usnadnit. Součástí
metodiky by měla být i soustava metrik, pomocí kterých by se dal popsat aktuální stav a nastavit
parametry stavu budoucího.
Vhodné by bylo i vytvoření jakési kostry nebo matice pro rozhodování o přechodu konkrétní
instituce. Ideově by mohla vycházet z metodiky naznačené výše. Různé součástí problému přechodu
by se pak daly rutinněji zanalyzovat a převést na měřitelná kritéria, která by bylo možné porovnat
s přínosy přechodem získaným. Žádoucí tedy je omezit do budoucna řešení přechodových a
implementačních problémů intuitivní cestou a nahradit ji v co nejvíce oblastech předem
promyšlenými, ověřenými, měřitelnými a standardními postupy.
Uvedená metodika a matice by se při vhodné generalizaci mohla vytvářet pro jakékoliv změny
síťové infrastruktury a problémy rozlehlých sítí obecně. Přechod verzí IP protokolu by pro ni mohl být
pouze jednou z oblastí aplikace.
- Vlastní podíl na vývoji standardů a aplikací
Některé oblasti nového protokolu ještě nejsou zcela pokryty definitivním řešením. Některé
oblasti nejsou dosud standardizovány a řada standardů ještě není rutinně implementována. Zde může
být prostor pro vlastní přínos každého ze čtenářů práce. Nicméně zapojení do činností pracovních
skupin IETF bude záležitostí spíše pro dlouholeté odborníky.
Řada aktivit je ale k dispozici i na nižší úrovni – je možné pokusit se implementovat některý ze
standardů, přenést některý mechanismus na dosud nevyužívanou platformu, vymyslet a realizovat
důležitý nástroj pro správu sítě či naprogramovat některou z aplikačních bran. Další důležitou oblastí
bude úprava starších aplikací na novou síťovou infrastrukturu, případně psaní nových uživatelských
programů, které využívají pokročilé vlastnosti IPv6. Bez existujících a stabilních služeb a aplikací by
byla nová kvalitní infrastruktura zbytečná.
11.5. Můj přínos k řešené problematice
Vzhledem k poměrně komplikovanému členění textu diplomové práce zde uvádím přehled částí
diplomové práce, které nebyly převzaté z žádného zdrojů uvedených v závěru práce. Jedná se o mé
vlastní úvahy, názory a zkušenosti získané v dříve v praxi, testováním v laboratorní síti nebo dotazy
odpovědným pracovníků firem. Tyto skutečnosti zatím nebyly nikde publikovány, jde o původní
součásti této diplomové práce. U každé z těchto částí jsem se snažil svůj postoj zdůvodnit a ukázat na
přínos a použitelnost zmíněného.
- Problémy návrhu IPv6 a úpravy aplikací (aplikace poznatků z implementace OSI protokolů).
strana 93
-
Přehled aktuálního komerčního použití v Čechách a v zahraničí (získáno z dotazníku odpovědným
osobám).
Ekonomické aspekty (zamyšlení nad vlivy a dopady IPv6 do ekonomiky, SWOT analýza podle
jednotlivých vlastností protokolu).
Prognózy a problémy (časové odhady nasazení založené na dřívějších pozorováních zavádění
podobných technologií, zamyšlení nad možnými obtíži).
Předpoklady přechodu, technologické a psychologické aspekty (uvažování a soupis
technologických stimulů a psychologických motivů, které pro přechod měly být důležité).
Zjištění stavu registrace a provedení registrace sítí (získáno sledováním informací registračních
institucí a vlastním registračním pokusem).
Zkouška implementace v malé síti (získáno z výsledků vlastních testování).
Nástin přechodu v síti VŠE (vlastní úvaha respektující znalost struktury sítě VŠE).
Uplatnění práce a další náměty na řešení oblasti (návrh činností, které by pomohly výzkum IPv6
posunout dále).
11.6. Závěrem
Protokol IPv6 je velikou výzvou pro dnešní Internet a potažmo všechny, kteří se jím zabývají.
Doufám, že se mi touto prací podařilo splnit cíle stanovené v jejím úvodu a čtenář získal alespoň
základní představu o nejdůležitějších možnostech nového internetového protokolu. Doufám také, že z
ní získal alespoň částečný rozhled po současném stavu zavádění protokolu do praxe u nás a ve světě a
že v něm vzbudila zájem o další informace a pokusy s IPv6.
To, zda k přechodu na IPv6 doopravdy dojde, není úplně jisté ani dnes, nicméně každým rokem
je patrný výrazný posun dál k nové infrastruktuře, který by měl dále pokračovat. Téměř jisté je, že na
masové zavádění IPv6 si ještě nějaký čas Internet počká, ale z postoje některých stran bych usuzoval,
že se mu nevyhne. To, kdy bude nová kvalitní infrastruktura k dispozici uživatelům v globálním
měřítku, nelze v tuto chvíli kvalifikovaně odhadnout. Před všemi zainteresovanými subjekty čeká ještě
mnoho práce, z nichž někteří o ní ještě nemusí vědět.
V Praze 30. dubna 2002
strana 94
Miroslav Matuška
12.
Literatura, použité zdroje
Tištěné prameny:
[1] – P.E.Miller, Mark A.Miller: Implementing IPv6: Supporting the Next Generation Internet
Protocols, IDG Books Worldwide, ISBN: 0764545892
[2] – W.Richard Stevens: TCP/IP Illustrated volume 1 – The protocols. Addison-Wesley, 8. vydání,
říjen 1996, ISBN 0-201-63346-9
[3] – M.Matuška : Semestrální práce na předmět IT_421: směrovače, studentská práce VŠE, prosinec
2000
[4] – L.Pavlíček: Rozvojový projekt e-INFRA VŠE v Praze, pracovní dokument VC VŠE, leden 2002
[5] – Graig Hunt: TCP/IP Network Administration, O’Reilly, 3. vydání, září 1993, ISBN 0-937175-82X
[6] – L.Dostálek, A.Kabelová: Velký průvodce TCP/IP a systémem DNS. 2. aktualizované vydání.
Computer press 2000, ISBN 80-7226-323-4
[7] – P. Satrapa a kol.: Průběžná zpráva o řešení výzkumného záměru TEN-155, rok 1999, kapitola
6.2, vydalo sdružení CESNET.
[8] – P. Satrapa a kol.: Průběžná zpráva o řešení výzkumného záměru TEN-155, rok 2001, kapitola
4.11, vydalo sdružení CESNET.
Elektronické prameny:
[9] – Steven Deering, Robert M. Hinden, Internet Protocol, Version 6 (IPv6) Specification , RFC
2460, prosinec 1998.
[10] – T. Narten, E. Nordmark, W. Simpson, Neighbor Discovery for IP Version 6 (IPv6) , RFC2461,
prosinec 1998.
[11] – S. Thompson, T. Narten, IPv6 Stateless Address Autoconfiguration , RFC2462 , prosinec 1998.
[12] – Conta, S. Deering, Internet Control Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) , RFC 2463, prosinec 1998.
[13] – J. McCann, S. Deering, J. Mogul, Path MTU Discovery for IP version 6 , RFC1981, srpen 1996
[14] – R. Hinden, B. Carpenter, L. Masinter, Format for Literal IPv6 Addresses in URL's , RFC 2732 ,
December 1999.
[15] – R. Coltun, D. Ferguson, J. Moy, OSPF for IPv6 , RFC 2740 , December 1999.
[16] – D. Borman, S. Deering, R. Hinden, IPv6 Jumbograms , RFC2675, , August 1999.
[17] – R. Hinden, S. Deering, IP Version 6 Addressing Architecture , RFC 2373, July 1998.
[18] – R. Hinden, M. O'Dell, S. Deering, An IPv6 Aggregatable Global Unicast Address Format, RFC
2374 , July 1998.
[19] – M. Crawford, A Method for the Tranmission of IPv6 Packets over Ethernet Networks,
RFC2464, December 1998.
[20] – P. Loshin: IPv6 všude. Článek v časopise Network Computing 06/2001,
http://www.networkcomputing.cz/archiv/ht0601.htm
[21] – P. Satrapa: články o IPv6 na serveru LUPA http://www.lupa.cz, články čísla 1026, 1028, 1335,
1977, 2031, 2162, 2192
[22] – různí autoři (M. Krsek, K. Chvalovský): články o IP na serveru LUPA http://www.lupa.cz,
články čísla 1133,1202, 1499, 1637
[23] – V. Kotal: sada dokumentů o IPv6 http://wilbury.sk/~techie/ipv6/ipv6-paper/
[24] – Archív článků Jiřího Peterky http://www.e-archiv.cz sekce technologie/počítačové sítě/IP sítě
[25] – Aktuální přiřazení čísel verzí http://www.iana.org/assignments/version-numbers
[26] – Přehled rodiny protokolů TCP/IP G. Kesslera http://www.garykessler.net/library/tcpip.html
[27] – Úvodní informace k IPv6 http://playground.sun.com/pub/ipng/html/
[28] – Přehled výzkumného projektu IPv6 v síti CESNET http://www.cesnet.cz/ipv6/
[29] – Projekt USAGI http://www.linux-ipv6.org/
[30] – Projekt KAME http://www.kame.net
[31] – Domovská stránka projektu 6bone http://www.6bone.net/
[32] – IPv6 Fórum http://www.ipv6forum.com/
[33] – Informační stránka o IPv6 http://www.ipv6.org
[34] – Internet Domain Survey http://www.isc.org/ds
strana 95
[35] – Pracovní skupina IPv6 http://www.ietf.org/html.charters/ipv6-charter.html
[36] – Konfigurace IPv6 v operačním systému Solaris http://www.optix.org/~dxy/solaris/ipv6
[37] – Konfigurace IPv6 v operačním systému Solaris http://www.ipv6.org/solaris-quick.html
[38] – Seznam poskytovatelů připojení IPv6
http://directory.google.com/Top/Computers/Internet/Protocols/IP/IPng/IPv6_Access_Providers/
[39] – Praktické odkazy k IPv6 http://hs247.com/
[40] – Poskytovatel tunelového připojení do IPv6 zdarma http://www.freenet6.net
[41] – J.Martan: IPv6 (Tech10), přednáška na konferenci Data Voice Video @ Cisco, říjen 2001
[42] – P.Gašpar: IPv6 – analýza a implementácia. Diplomová práce, Univerzita Komenského
Bratislava, duben 2000
Informace získané dotazy odpovědným osobám přímo v podnicích (viz. dopis v příloze práce)
strana 96
13.
Slovníček pojmů a zkratek
6bone – Zkušební síť, na které probíhá testování IPv6 návrhů, implementací a provozu. Dnes asi
nejvíce rozvinutá a nejpřístupnější IPv6 síť.
6over4 – Přechodový mechanismus umožňující automaticky tunelovat data s využitím překladače přes
IPv4 infrastrukturu.
6to4 – Přechodový mechanismus umožňující automaticky tunelovat data s využitím multicastových
přenosů přes IPv4 infrastrukturu
A – DNS záznam udávající číselnou adresu k doménovému jménu v IPv4.
AAAA – DNS záznam udávající číselnou adresu k doménovému jménu v IPv6.
AH – Authentication Header. Rozšiřující autentizační hlavička v IPv6.
anycast – Pojem pro výběrové směrování a adresy. Anycast adresu může mít více zařízení najednou,
ale paket bude doručen pouze na to nejbližší.
API – Aplikační programové rozhraní/Application Programming Interface. Slouží programátorů pro
používání systémových funkcí nižší úrovně
APNIC – Registrační autorita Internetu pro Asii a tichomoří
ARIN – Registrační autorita Internetu pro americký kontinent
ARP – Address resolution protocol. Protokol sloužící k překladu IP adres na MAC adresy
ARPANET – Původní síť, ve které začal poprvé fungovat protokol TCP/IP. Nyní již neexistuje
ASP – Application Service Provider/poskytovatel aplikačních služeb. Instituce, která svým
zákazníkům poskytuje dohodnuté služby s přidanou hodnotou pomocí elektronických sítí.
ATM – Asynchronous Transfer Mode. Přenosová technologie druhé vrstvy s mnoha službami.
V současné době je spíše na ústupu
best-effort – Maximální snaha. Negarantované poskytování přenosových služeb na principu „vše, co
je v možnostech zařízení“
BIA, BIS – Přechodový mechanismus implementovaný přímo v koncovém uzlu, kde také dochází
k překladu protokolových struktur z jedné verze do druhé
broadcast – Všesměrové vysílání (všem uzlům v dané síti)
BSD – Berkeley Software Distribution. Používáno v souvislosti s operačními systémy typu Unix
(FreeBSD, OpenBSD apod.).
CESNET – Česká vysokorychlostní a výzkumná akademická síť propojující vysoké školy a ústavy
Akademie věd v ČR
CIDR – Classless Inter Domain Routing/Beztřídní směrování. Mechanismus umožňující přizpůsobit
adresy a směrovací záznamy podle potřeby velikosti sítě a jejich snadnou agregaci. Umožnil
opustit původní pojetí tříd IPv4 adres (A,B,C).
CNAME – Alias v DNS databázi na jinou adresu.
CSF – Critical Success Factors/Kritické faktory úspěchu. Nutné podmínky, které je potřeba dodržet,
aby mělo řešení úspěch.
DES, CBC režim – Digital Encryption Standard/Šifrovací metoda založená na symetrickém
algoritmu.
DHCP – Dynamic Host Control Protocol. Konfigurační protokol, který umožní ze serveru získávat
klientům základní konfigurační informace o jejich adrese, výchozí bráně a podobně.
DNS – Domain Name System/Systém doménových jmen. Internetový systém umožňující překládat
číselné adresy na jména a naopak.
ESP – Encapsulating Security Payload. Rozšiřující šifrovací hlavička v IPv6.
Ethernet – Nejpoužívanější síťová technologie druhé vrstvy v lokálních sítích.
EUI-64 – Standardní identifikátor libovolného síťového rozhraní podle organizace IEEE. V IPv6 je
použit pro vytvoření posledních 64 bitů adresy automatickým způsobem z MAC adresy.
FTP – File Transfer Protocol. Jeden z protokolů založených na TCP/IP, sloužící k přenosu souborů
mezi dvěma uzly.
GPRS – Technologie paketového přenosu v bezdrátových GSM sítích druhé generace.
GSM – Digitální celosvětový systém bezdrátových sítí sloužící primárně k použití mobilních telefonů.
HTTP – Hypertext Transfrer Protocol. Jeden z protokolů založených na TCP/IP, sloužící k přenosu
hypertextového obsahu, nejčastěji pak stránek systému WWW.
strana 97
IANA – Internet Assigned Numbers Authority. Organizace přidělující význam některým konečným
zdrojům Internetu (např. číselným rozsahům).
ICMP – Internet Control Message Protocol. Řídící a servisní protokol k IP.
ICT – Informační a komunikační technologie.
IEEE – Institute of Electrical and Electronic Engineers. Standardizační instituce v oblasti elektroniky
a také výpočetní techniky
IETF – Internet Engineering Task Force. Organizace neformálně sdružující řadu pracovních skupin,
které se podílí na vývoji Internetových standardů
IOS – Operační systém pro směrovače firmy Cisco.
IP – Internetový protokol. Standard síťové vrstvy v rozlehlých sítích.
IPSec – Definice zabezpečujících doplňků a bezpečnostních mechanismů k IPv4 a IPv6.
IPv4 – IP verze 4. V současnosti používaná verze protokolu.
IPv6 – IP verze 6. Nově navržená budoucí verze protokolu.
IS – Informační systém.
ISATAP – Intra-Site Automatic Tunnel Addressing Protocol. Přechodová technologie umožňující
existovat IPv6 uzlům v IPv4 lokální síti.
ISDN – Integrated Subscriber Digital Network. Přístupová digitální technologie druhé vrstvy dostupná
po telefonních linkách.
ISOC – Internet Society. Zastřešující organizace nad všem dalšími Internetovými institucemi,
„vedení“ Internetu.
ISP – Internet Service Provider/Poskytovatel internetového připojení.
IT – Informační technologie
LINUX – Operační systém unixového typu vyvíjený širokou komunitou programátorů s otevřeným
zdrojovým kódem.
LIR – Local Internet Registry/Lokální registrátor internetových adres.
loopback – Zpětné rozhraní z uzlu na ten samý uzel
MAC – Media Access Control. Jedna ze součástí druhé vrstvy síťových technologií. Zajišťuje
dvoubodový přenos a adresaci místních rozhraní na druhé vrstvě.
mrouter – Směrovač schopen směrovat skupinové (multicast) přenosy.
MTU – Maximum Transfer Unit. Parametr spoje druhé vrstvy, který udává, jaký největší objem dat
lze přenést v jednom rámci.
multicast – Skupinové přenosy. Data se vysílají z jednoho zdroje více příjemcům najednou při šetření
přenosového pásma.
MX – Záznam v DNS určující server, který bude pro daný uzel zpracovávat příchozí poštu.
NAT – Network Adress Translation. Mechanismus z IPv4, umožňující zaměnit v paketech veřejnou a
soukromou adresu podle určité asociace. S využitím čísel portů lze nahrazovat více soukromých
adres jednou veřejnou adresou a šetřit tak veřejné IP adresy.
NAT/PT – Network Adress Translation/Protocol Trnaslation. přechodový mechanismus který
překládá IP a ICMP pakety mezi IPv4 a IPv6 sítěmi a adresy jim přiděluje podle dříve získané
asociace.
NLA – Next Level Aggregator/Agregátor další úrovně. Instituce v hierarchii připojovacích sítí do
Internetu, která není ani na spodním konci, ani na vrcholu hierarchie. Typicky jde o
přístupového poskytovatele internetového připojení.
NS – Záznam v DNS určující jmenný server pro tuto doménu.
OSPF – Směrovací protokol založený na tvorbě mapy sítě a zjišťování stavu spojů (link state).
PASNET – Pražská akademická síť propojující některé Pražské vysoké školy a ústavy Akademie věd.
patch – Úprava nějaké časti programového systému.
PDA – Personal Digital Assistant. Počítač do dlaně.
PPP – Point To Point Protocol. Spojový protokol druhé vrstvy používaný na dvoubodových spojích,
nejčastěji na sériových a telefonních linkách. Jeho použití je ovšem univerzální jako jednoduchá
druhá vrstva na libovolném médiu.
prefix – Adresa sítě. Počáteční část IP adresy určující síť, nikoliv koncový uzel. Velikost sítě je
nepřímo úměrná bitové délce prefixu.
provider – Poskytovatel.
strana 98
RFC – Request For Comments. Dokument vydaný IETF upravující určitou oblast. Může jít o standard
nebo informační text. Vzniká většinou jako konsenzus pracovních skupin IETF.
RIP – Směrovací protokol založený na výměně směrovacích tabulek sousedních směrovačů (distance
vector).
RIPE NCC – Registrační autorita Internetu pro Evropu a Afriku.
router – Směrovač, síťový prvek třetí vrstvy.
routing – Směrování. Proces, kterým se podle IP adresy v paketu určí další cesta, kudy je potřeba
paket poslat.
RSVP – Resource Reservation Setup Protocol. Rezervační protokol, umožňující vyhradit na
směrovačích po přenosové cestě zdroje, požadované určitou aplikací.
RTP – Real Time Protocol. Protokol sloužící k přenosu dat aplikací pracujících v reálném čase a
citlivé na zpoždění a šířku pásma.
SCP – Secure Copy. Zabezpečený způsob přenosu souborů mezi dvěma uzly, vychází z mechanismu
SSH.
SLA – Site Level Aggregator/Agregátor koncové sítě. Instituce v hierarchii připojovacích sítí do
Internetu, která je na spodním konci. Typicky jde o konečného zákazníka poskytovatele
internetového připojení.
SMTP – Simple Mail Tranfer Protocol. Protokol založený na TCP/IP sloužící k posílání poštovních
zpráv dalším uživatelům Internetu.
Solaris – Unixový operační systém firmy Sun Microsystems.
SSH – Secure Shell. Mechanismus zabezpečeného vzdáleného přihlášení na jiný počítač.
SSL – Secure Sockets Layer. Prostředí pro vytváření zabezpečených přenosů v rodině protokolů
TCP/IP.
switch – Přepínač, síťový prvek druhé vrstvy.
SWOT – Analýza současné situace nějaké záležitosti. Zkoumají se silné stránky (strengths ,S), slabé
stránky (weak, W), příležitosti (opportunities, O) a hrozby (threats T).
TCP – Transmission Control Protocol. Protokol transportní vrstvy bezprostředně související s IP a
využívající jeho služeb. Jde o spojovaný přenos.
TLA – Top Level Aggregator/Vrchní agregátor. Instituce v hierarchii připojovacích sítí do Internetu,
která je na vrcholu hierarchie (na páteři Internetu). Typicky půjde o velkého telekomunikačního
operátora s globální přítomností.
TRT – Transport Relay Translator. Přechodový mechanismus, pracující na transportní vrstvě a
podporující pouze některé její protokoly (nikoliv celé IP).
UDP – User Datagram Protocol. Protokol transportní vrstvy bezprostředně související s IP a
využívající jeho služeb. Jde o ne spojovaný přenos.
UMTS – Technologie mobilních sítí třetí generace, nabízejících především vyšší přenosové pásmo
než generace předchozí.
unicast – Běžný přenos mezi dvěma uzly v Internetu.
VC VŠE – Výpočetní centrum Vysoké školy ekonomické v Praze.
VPN – Virtual Private Networks/Virtuální privátní sítě. Zabezpečené propojení více oddělených sítí,
například přes veřejný Internet.
WFQ – Weighted Fair Queuing. Jeden ze způsobů frontování a prioritizace paketů na směrovačích.
WWW – World Wide Web. Celosvětový systém HTTP serverů, nabízejících hypertextový obsah
k prohlížení klientům.
strana 99
14.
Seznam obrázků a tabulek
Obrázek 1: Graf vývoje počtu uživatelů Internetu (str. 12)
Obrázek 2: Původní třídy IP adres (str. 13)
Obrázek 3: Základní hlavička IPv6 paketu (str. 19)
Obrázek 4: Doplňující hlavičky IPv6 paketu (str. 21)
Tabulka 1: Počáteční rozdělení adresního prostoru IPv6 (str. 23)
Obrázek 5: Příklad zápisu základní formy IPv6 adresy (str. 24)
Obrázek 6: Příklad zápisu zkrácené formy adresy (str. 24)
Obrázek 7: Příklad kombinovaného zápisu IPv4 v IPv6 adrese (str. 24)
Obrázek 8: Příklad číselného zápisu adresy v URL (str. 24)
Obrázek 9: Příklad zápisu sítě a uzlu v této síti (str. 24)
Obrázek 10: Členění globální adresy (str. 25)
Obrázek 11: Členění multicastové adresy (str. 26)
Obrázek 12: Možné další členění pole NLA (str. 57)
Tabulka 2: Počáteční přiřazení prefixů SubTLA (str. 59)
Obrázek 13: Fyzické schéma testovací IPv6 sítě (str. 62)
Obrázek 14: Logické schéma testovací IPv6 sítě (str. 63)
Obrázek 15: Schéma při simulovaném výpadku jednoho ze spojů (str. 69)
Obrázek 16: Přístup webovým prohlížečem Mozilla na webový server astra.ipv6 (str. 72)
Obrázek 17: Přístup webovým prohlížečem Mozilla na server www.kame.net (str. 73)
Tabulka 3: Přehled výsledků testování služeb FTP a SCP (str. 75)
Tabulka 4: Přehled označení číselných verzí protokolu IP (příloha)
Obrázek 18: Symbol projektu KAME – želva (závěrečný list)
strana 100
Přílohy
Návrh síťových protokolů v síti ARPANET/Internet - TCP/IP nebo OSI?
Protokoly TCP/IP, označované jako rodina ministerstva obrany Spojených států, Department of
Defence – DoD, nebyly jediné standardy, na kterých byly stavěny rozlehlé sítě. Šlo sice o otevřené, ale
proprietární řešení, použité pro konkrétní potřebu (zadání) a implementované tak, aby bylo ve
stávajících podmínkách dobře prakticky použitelné. Neuvažovalo detailnější specifikaci aplikačních
vrstev (programů, které budou přenosový protokol používat), ani vrstvy síťového rozhraní
(technologie přenosového média). Mělo jít spíše o jednotící protokol umožňující komunikovat na
libovolném médiu mezi libovolnými sítěmi a libovolnými aplikacemi. Jak TCP, tak IP v sobě obsahují
pouze ty nejzákladnější služby přenosu dat, které od nich byly požadovány, a veškeré nadstandardy a
podpůrné služby přesunuli tvůrci protokolu na programátory aplikací. Idea byla taková –
nekomplikovat přenos složitými rutinami a nechť si program funkci, kterou potřebuje, implementuje
sám (až ji bude potřebovat). Důraz u TCP/IP byl kladen na životaschopnost v praxi – než se stal návrh
standardem, musel být implementován a správně fungovat.
Souběžně s rozvojem počítačových sítí se standardizace chopila i instituce ISO (International
Standard Organization), která specifikovala sedmivrstevný referenční model OSI (Open Systems
InterConnect) počítačových sítí. Pro každou vrstvu pak byly pracovními skupinami navrhovány
protokoly, které měly funkce a služby dané vrstvy plnit. Vznikaly jako co nejobecnější a nejširší záběr
tak, aby vyhověly různým požadavkům na různé přenosové služby. Psaní aplikací by bylo jednodušší,
protože velká část služeb by již byla implementována na nižší vrstvě a programátor by se o její
implementaci nemusel starat. Z hlediska návrhu byly velmi dobře promyšlené a propracované.
OSI protokoly však vznikaly spíše „od stolu“ a do praxe se dostávaly velmi pomalu, nejspíše
právě díky náročným požadavkům na funkčnost každé vrstvy. Široký rozptyl služeb způsoboval
velkou režii chodu protokolů, obtížnou implementaci a z toho plynoucí pomalé rozšiřování a nízké
rozšíření po světě.
Vzhledem k propracovanému návrhu OSI modelu a protokolů bylo na konci osmdesátých let
minulého století rozhodnuto o všeobecném přechodu TCP/IP sítí na protokoly OSI. Standardy DoD
byly považovány za dobré a životaschopné, ale díky jednoduchému a proprietárnímu návrhu chápany
jen jako přestupní technologie k dokonalejšímu. Implementace OSI protokolů se očekávala každým
rokem a již od roku 1990 neměl být TCP/IP šířeji používán
Vývoj TCP/IP ovšem pokračoval dál a řešil jednotlivé nové požadavky na síťové služby
jednoduchými funkčními implementacemi. Díky jeho otevřenosti a komunitě vývojářů se z něj de
facto univerzální propojovací standard stal. Přínosy (novinky), které měl přechod na OSI přinést, se
ukázaly jako malé ve srovnání s náročností přechodu a implementace. Některé použitelné věci
z návrhu OSI byly dodány do IP a přechod najednou nebyl tak nutný. Funkční implementace OSI se
stále oddalovaly, aby splnily náročné požadavky.
Zatímco autoři RM ISO/OSI usilovali od začátku o dokonalé řešení splňující mnoho
různorodých požadavků (a pak narazili na problémy), autoři TCP/IP šli cestou od jednoduššího řešení
směrem k řešení dokonalejšímu, cestou postupného zdokonalování a obohacování. Na rozdíl od
standardizace ve světě TCP/IP (viz výše), se u ISO/OSI se otázka praktické realizace řešila až poté, co
se nějaký návrh stal standardem a začalo se uvažovat o tom, jak ho implementovat.
Zatímco připojení k IP síti bylo (a je) relativně snadnou záležitostí, pro interoperabilitu s OSI
protokoly bylo potřeba provést více práce. To společně s výše zmíněnými příčinami a neexistencí širší
základny OSI implementací jsou podle mého názoru příčiny exponenciálního růstu Internetu a
nevýrazného pronikání OSI protokolů na přelomu osmdesátých a devadesátých let.
Na začátku let devadesátých, kdy se od rychlého přechodu na OSI ustoupilo, byly z obou
vývojářských táborů snahy sjednotit obě prostředí a to dobré z obou integrovat no nového standardu.
Bohužel, ani technologie TP4 (transportní vrstvy), ani CLNP (síťové vrstvy) se mnoho nerozšířila.
A jaký je současný stav v celosvětových sítích? Zatímco referenční model OSI zůstal často
používán jako velmi dobrá pomůcka pro veškeré aktivity kolem počítačových sítí (učení, předávání
zkušeností, popisu, návrhu, správy, implementace aj.), navržené protokoly vrstev již zřejmě použity
nebudou, rodina standardů TCP/IP i přes dílčí problémy (viz dále) vládne silou neztenčenou.
strana 101
Instituce a správa Internetu
Internet je ze své podstaty decentralizovanou sítí (nemá jednotného vlastníka a jednotného
operátora). Původní protokoly byly vyvinuty z veřejných prostředků a jsou veřejným vlastnictvím.
Dnes se vyvíjí zejména za prostředky soukromých firem v komerční sféře, ale jeho otevřený charakter
zůstává stejný. O TCP/IP dnes rozhoduje široká odborná veřejnost při standardizačním procesu.
Nicméně některé aktivity ponechat na volném rozhodnutí subjektů nelze. Jde zejména o
přidělování číselných a jmenných adres, standardizaci, vývoj protokolů (například právě vývoj IPv6) a
další. Tyto záležitosti řeší skupina nevládních a nezávislých institucí, mezi které patří:
ISOC: Internet Society (http://www.isoc.org), která slouží pro koordinaci a zastřešení
centrálních aktivit Internetu. Vznikla v době přechodu Internetu do komerční sféry a ústřední
administrace musela být předána jiné instituci. Zabývá se mimo jiné standardizačním procesem.
IETF: Internet Engineering Task Force (http://www.ietf.org) – volně organizované seskupení
pracovních týmů řešících technické otázky Internetu, včetně nových protokolů a standardů. V jeho
rámci existuje mimo jiné i několik skupin řešících síťový protokol nové generace (IPng, nyní již
konkrétněji IPv6). Postupy práce tvůrčích skupin a standardizační proces je podrobněji popsán
v dokumentech RFC 2028, 2031 a 2418. Členství v IETF není formální záležitostí – každý, kdo se
podílí na jeho práci (i třeba jen nápady), se za člena může považovat.
IESG: Internet Engineering Steering Group (http://www.iesg.org) - řídící výbor pro IETF,
organizuje jeho činnost a řídí práci, formálně vydává přijaté standardy pomocí ISOC
IRTF: Internet Engineering Research Force (http://www.irtf.org) – zahrnuje vědeckovýzkumné skupiny řešící dlouhodobé problémy a náměty budoucího rozvoje Internetu.
IANA, později ICANN: Internet Assigned Numbers Authority / Internet Corporation for
Assigned Names and Numbers (http://www.icann.org) – přiděluje rozsahy IP adres, obsahově
spravuje domény nejvyšší úrovně, deleguje pravomoci na subdomény, přiděluje čísla „dobře
známých/well known“ portů a podobně.
V současné době mohou nová řešení vzniknout i v komerční sféře – je-li proprietární řešení
zveřejněno a je považováno za dobré, je možné jej schválit za standard. Standardy týkající se TCP/IP
jsou vydávány formou RFC a STD dokumentů, které jsou veřejně přístupné. Nejde o standardy de iure
(ISOC není standardizační organizací), ale de facto – v praxi jsou důsledně dodržovány.
Verze protokolu IP – proč právě 6?
Číselné označení současně používané a nejrozšířenější verze IP protokolu je 4 (IPv4,
specifikována v RFC 791), nyní v [25]. Nově navržená a v této práci podrobněji analyzovaná verze má
číslo 6 (IPv6, specifikovaná v RFC 1752). I když by se mohlo logicky zdát, že číslování verzí
odpovídá vývojovému stupni IP protokolu a že tvůrci vycházeli z verze 1 a postupnými úpravami se
dostali k verzi 4, není tomu tak. Stejně tak pátá verze IP protokolu chybí jako mezičlánek k šesté verzi
jen zdánlivě. Čísla totiž nebyla přidělována postupně jednomu vylepšovanému protokolu, ale byly jimi
označovány síťové protokoly k IP příbuzné a alternativy nových verzí – vzájemně rovnocenných
návrhů pro IP nové generace (IPng). Široké implementace se nicméně mohla dočkat pouze jediná.
Současné přidělení čísel verzí podle organizace IANA/ICANN je následující:
Číselné označení verze Klíčové slovo
Popis verze
0
Rezervováno
1-3
Nepřiřazeno
4
IP
Internet protocol
5
ST
ST Datagram mode
6
IPv6 (dříve SIP)
Internet protocol verze 6
7
TP/IX
TP/IX: The Next Internet
8
PIP
P Internet Protocol
9
TUBA
TCP and UDP with bigger addresses
10-14
Nepřiřazeno
15
Rezervováno
nepřiřazeno
CATNIP
Common Architecture for Next
Generation Internet Protocol
strana 102
Z tabulky je zřejmé, že finální návrh IP protokolu byl označen číslem 4 a předchozí zkušební
verze se nedočkaly implementace v rozsahu, který by nutil používat jejich čísla v IP paketech (starší
implementace než IPv4 se již dnes nepoužívají). Společně se snahou najít řešení pro nedokonalosti IP
protokolu byla experimentálním návrhům přiřazována čísla, pod kterými je jejich tvůrci zkoušeli.
Jaké návrhy se pro IPng se na konci osmdesátých a v devadesátých letech minulého století
objevily a byly v rámci IETF rozpracovány? Pracovní skupina k protokolu TP/IX (neboli IPv7 podle
RFC 1475) si dala za cíl rozšířit adresní prostor IP na 64 bitů a zvýšit rozsah čísel TCP/UDP portů na
32 bitů. Návrh PIP se později spojil s iniciativou SIP pro návrh protokolu SIPP, který umožňoval
prodlužovat síťovou adresu v budoucnu podle potřeby (používal proměnnou délku adresy). TUBA
(neboli IPv9 podle RFC 1347 ,1526 a 1561, dříve Simple CLNP) je založená na principu síťového OSI
protokolu CLNP, kde se používají adresy proměnné délky. Další navržený protokol CATNIP (podle
RFC 1707) počítal s integrací protokolů CLNP, IP a IPX do jednoho tak, aby transportní protokoly
vyšších vrstev (CLTP, TCP, UDP, SPX a další) mohly používat právě tento jeden jediný a aby se
odstranila omezení délky IP adresy.
Poslední v tabulce zmíněný protokol („IPv5“, RFC 1190), ST Datagram mode, byl navržen pro
proudovou (stream) alternativu k IPv4 na konci sedmdesátých let a měl poskytnout garantované
služby při přenosu v Internetu. Pro vývoj IPv6 není relevantní.
V roce 1994 proběhlo porovnání rozpracovaných návrhů a kritické posouzení vzhledem
k předpokladům tvůrčí komunity a požadavkům, které byly na nový protokol kladeny. Každý návrh
měl silná místa a slabiny a širokou diskusí se podařilo dojít ke konsenzu, že základem pro další
rozpracovávání IP protokolu nové generace (IPng) se má stát upravený SIPP s fixní délkou adresy 16
bajtů.
Organizace IANA pak určila tomuto návrhu číslo verze 6, které bylo při předchozích
přidělováních použito pro původní návrh SIP. V lednu 1995 bylo vydán zastřešující RFC dokument
číslo 1752 a od této doby lze oficiálně namísto o obecném protokolu IPng hovořit už o IPv6.
Každý z návrhů (TUBA, SIPP, CATNIP a další) měl pro požadované využití určité výhody a
nevýhody. Posouzením stavu vývoje protokolů byl pro další rozpracování určen návrh SIPP
s prodloužením adresy na fixní délku, přidáním podpory automatické konfigurace, požadavkem pro
vyšší vrstvy (např. TCP) na využívání celé 16 bajtové adresy a několika dalšími doplněními.
strana 103
Předpoklady a očekávání od protokolu nové generace
V rámci IETF vznikly pracovní týmy, které se snažily vyřešit problém komplexně a od základů
znovu. Nedalo se čekat nekonečné prodlužování funkčnosti původního protokolu a zkoumalo se, jak
při zachování stávajících pozitiv odstranit negativa dlouhodobě. Pro návrh takového řešení byla
stanovena následující technologická kritéria (podle RFC 1752):
- Úplná specifikace – specifikace nového protokolu musí být kompletní včetně všech mechanismů.
Je požadováno předložení hotových dokumentů, nikoliv odkazu na budoucí práci.
- Jednoduchost architektury – protokol síťové vrstvy by měl být co nejjednodušší. Všechny funkce,
které by bylo vhodné implementovat na jiné vrstvě, by neměly být v IP.
- Škálovatelnost – nový protokol musí umožnit adresovat alespoň 10^9 koncových sítí.
- Flexibilita topologie – směrovací protokoly musí fungovat na různých druzích síťových topologií.
- Výkon – směrovače implementující nový protokol musí být schopny zpracovat a přenášet jeho data
na rychlostech plně využívající dostupná vysokorychlostní média.
- Možnost přechodu z původní verze – nový protokol musí obsahovat jasný plán přechodu z IPv4 na
standard nové generace.
- Nezávislost na přenosovém médiu – protokol musí fungovat na mnoha druzích přenosových
technologií používaných v LAN, MAN a WAN sítích.
- Podpora datagramové služby – protokol musí obsahovat podporu nepotvrzované datagramové
přenosové služby (analogii UDP), stejně jako spojované služby (analogii TCP).
- Snadná konfigurace – protokol musí umožnit bezproblémovou a distribuovanou konfiguraci
koncových zařízení. Je požadována automatická konfigurace koncových uzlů a směrovačů.
- Bezpečnost – nový protokol musí poskytnout bezpečnou síťovou vrstvu.
- Jedinečná označení – v celém globálním Internetu musí být síťovým zařízením přidělována
jedinečná označení. Jména nemusí mít význam pro směrování, topologii a umístění sítí.
- Přístupnost standardů – dokumenty, které popisují protokoly IP nové generace, by měly být volně
dostupné, stejně jako RFC dokumenty k IPv4. Za poskytování nebo používání standardů nesmí být
vybírány žádné licenční poplatky.
- Podpora multicastu – protokol musí umět přenášet a dynamicky směrovat jak dvoubodové, tak
hromadné přenosy (unicast i multicast).
- Rozšiřitelnost – návrh nového protokolu musí být rozšiřitelný. Musí být schopen přijmout budoucí
požadavky na služby Internetu.
- Podpora tříd služeb – síťová zařízení musí být schopna členit zpracovávané pakety do určitých
tříd a pro každou třídu poskytnout specifikovaný rozsah služeb.
- Mobilita – protokol musí podporovat mobilní uzly a i celé sítě.
- Řídící protokol – návrh musí obsahovat podporu pro testování a analýzu provozu sítí (například
nástroje ping a traceroute)
- Tunelování – návrh musí umožnit budovat privátní propojovací sítě přes infrastrukturu veřejného
Internetu. Musí být podporovány tunely jak pro protokol IP, tak pro jiné (AppleTalk, CLNP)
-
-
Očekávání od IPv6
Později byla výše uvedená obecná kritéria konkretizována už přímo na protokol IPv6 takto:
Rozšířené možnosti adresování a směrování - větší šířka adresy umožní více adresovatelných
uzlů, více úrovní adresní hierarchie a jednodušší možnost automatické konfigurace adresy.
Multicast bude podporován v základní implementaci.
Zjednodušený formát hlavičky – některé položky z hlavičky IPv4 paketu byly vypuštěny nebo
přesunuty do volitelných hlaviček v IPv6, aby se nezvyšovala režie hlavičkových dat a usnadnilo
se zpracování pro směrovače
Podpora pro rozšiřující hlavičky a parametry – doplňující hlavičky se budou nacházet mezi
základní IPv6hlavičkou a hlavičkou transportní vrstvy. Ty doplňkové hlavičky, které nemusí
zpracovávat směrovače po cestě, ale jen koncové uzly, budou na konci doplňkového seznamu pro
zjednodušení zpracování. Velikost doplňujících hlaviček nebude limitována.
Podpora autentizace a soukromí – IPv6 bude obsahovat mechanismus, který umožní ověřit
integritu dat a to, že odesílatelem je skutečně uzel, který je v paketu uveden. To by měly
strana 104
-
obsahovat všechny implementace. Šifrování dat bude také podporováno v základním návrhu a pro
implementace velmi doporučeno.
Podpora automatické konfigurace – Bude podporováno více forem automatické konfigurace uzlu,
od zcela samostatného sestavení adresních informací uzlem v izolované síti až po dynamickou
konfiguraci z jiného serveru (DHCP)
Podpora směrování podle adresy odesílatele – Pomocí doplňující hlavičky bude možné
specifikovat doplňující informace pro směrování, například směrovače, přes které má paket projít
a informace pro směrování podle adresy zdrojového uzlu.
Přenos dat se zaručenou kvalitou – Pakety bude možné označovat značkami („barvit“) a určovat
tak datové toky s rozdílnou prioritou (například služby v reálném čase)
Jednoduchý a pružný přechod z IPv4, který zahrnuje 4 cíle:
• Přírůstkový upgrade – Existující IPv4 zařízení mohou být o implementaci IPv6 rozšířena
v libovolném čase, bez závislosti na stavu implementace na ostatních zařízeních
• Přírůstkové rozvíjení – Zcela nové uzly mohou být instalovány v libovolném čase bez
jakýchkoli nutných podmínek
• Snadné adresování – Po upgradu protokolu na novou verzi mohou uzly používat dál své
stejné adresy, nemusí se jim přiřazovat nové.
• Nízké počáteční náklady – Při přechodu jsou vyžadovány jen malé přípravné práce.
strana 105
Pracovní skupiny IETF, které se záležitostmi kolem IPv6 zabývají
Jádrová pracovní skupina
Na začátku roku 1995 byla sestavena pracovní skupina pro IPv6 (IPng Working group), aby na
základě předpokladů a očekávání vytvořila podrobné specifikace jádrové funkcionality nové rodiny
protokolů. Při jejich práci se řídí doporučeními uvedenými v dokumentu RFC 1752 a pracuje pod
vedením Steva Deeringa (Cisco, dříve Xerox) a Roberta Hindena (Nokia, dříve Sun Microsystems).
Primárním úkolem této skupiny bylo a je tvořit dokumenty, které definují základní funkce,
interakce, předpoklady a formáty paketů IPv6. Mezi dokumenty a úkoly patří zejména:
- přehledový dokument o IPv6
- detailní provozní specifikace
- specifikace adresní architektury IPv6
- specifikace zapouzdření IPv6 přes různá přenosová média na linkové vrstvě, např. [19]
- specifikace pro přenos paketů delších než 64KB
- specifikace nutných rozšíření jmenného systému DNS
- specifikace řídících protokolů (ICMP, IGMP a identifikaci sousedních směrovačů) pro IPv6
- specifikace nalézání MTU (velikosti maximální přenosové jednotky 2. vrstvy) po cestě paketu
- specifikace tunelování IPv6 v IPv6
- popis navrženého adresního formátu a plánu přiřazování uzlům
- koordinace se skupinou zabývající se automatickou konfigurací (viz dále)
- koordinace se skupinami zabývajícími se přechodem na nový protokol (NGRANS a TACIT, viz
dále)
- specifikace autentizačních a šifrovacích hlaviček
Skupina by dále měla zvážit rozšíření protokolu o různé způsoby komprese hlavičky v nativním
a zapouzdřeném IPv6 protokolu.
Přechod ze stávajícího protokolu
IPv6 se nebude zavádět do úplně nového prostředí, ale do existujícího IPv4 Internetu. To je
velmi komplikovaný systém se složitými a někdy neočekávanými vazbami mezi jeho prvky. Není
možné „postavit vedle“ nový Internet a přejít na novinky rázem a najednou – stávající služby už mají
takový charakter, že by jejich výpadek způsobil vážné problémy v navazujících oblastech ekonomiky.
Pro hladký přechod z IPv4 na IPv6 je potřeba určit řadu postupů, technologií a migračních strategií.
Těmito úkoly se zabývají přechodové pracovní skupiny v rámci IETF, a to jak z krátkodobého,
tak z dlouhodobého hlediska.
Krátkodobé hledisko (pracovní skupina NGTrans) zahrnuje [35]:
- Definici procesů, kterými se Internet dostane z fáze IPv4 na IPv6. Jde o vysvětlení pro obecnou
internetovou veřejnost, které mechanismy budou při přechodu použity, předpoklady na síťovou
infrastrukturu a popis funkcionality, kterou budou moci vývojáři v jednotlivých přechodových
fázích využívat.
- Definici povinných a volitelných opatření, které by výrobci měli implementovat ve směrovačích,
koncových uzlech a dalších komponentách Internetu. Mimo jiné jde o zavádění dvojitých IPv4/6
protokolových implementací, mechanismy překladů hlaviček a postupů při komunikaci uzlů
používajících jinou verzi IP.
- Definici konkrétního provozního přechodového plánu. Tento plán pak budou moci využít síťoví
operátoři a uživatelé k přechodu.
Dlouhodobé hledisko (skupina TACIT) zahrnuje výzkum:
- Jak přejít na nový protokol při zachování heterogenity a decentralizované správy sítí.
- Porozumění charakteristikám dlouhodobé koexistence obou protokolů v jedné síti.
- Testování přechodových mechanismů tak, aby byly robustní i v podmínkách skutečného Internetu
a jejich nasazování probíhalo bez narušení stávajících služeb.
Dlouhodobá skupina bude zaměřena více provozně a výsledkem jejího zkoumání mají být
návody pro uživatele a správce dotčených sítí. Ty budou obsahovat:
- Detailní popisy problémových oblastí v přechodu a koexistenci protokolů (předvídané, zjištěné
z jiných sítí a pozorované v IP síti)
strana 106
-
Doporučení pro specifické testovací procedury
Doporučení pro koexistenci provozních postupů
Doporučení pro usnadnění plánování decentralizovaného přechodu
Dopad na IETF a ne IETF standardy
Vznikem nového protokolu bude ovlivněno mnoho standardů, zejména organizace IETF (RFC
dokumenty), ale i jiných institucí. V některých případech bude stačit jen zaměnit formulaci „32-bitová
IP adresa“, protože protokol není dále v textu použit. V dalších případech bude potřeba změnit návrh
protokolu včetně formátu paketů. Někde půjde jen o změnu datového elementu (prodloužení místa na
uložení IP adresy), která nebude mít vliv na funkční princip.
Někde ovšem bude potřeba změnit i smysl fungování celého protokolu (například bezpečnostní
mechanismy nebo postup směrování podle adresy odesílatele). Protokoly spoléhající na funkcionalitu
IPv4 budou muset být znova navrženy, nebo se místo nich musí použít jiná, odpovídající funkce IPv6.
Na změnách v navazujících protokolech budou pracovat nové i stávající skupiny IETF. IPng
Working Group bude zodpovědná za definice nové verze protokolů ICMP, ARP/RARP a UDP.
Existující skupiny provedou revize ve směrovacích protokolech RIPv2, IS-IS, iDRP a SDRP. Pro
tvorbu protokolu OSPF nové generace bude muset být ustavena separátní pracovní skupina.
Stejným způsobem vznikne i TCPv6, nové verze SNMP, DNS, NTP, NETBIOS, OSI přes TCP,
Kerberos a specifikace IP přes různé druhy médií (IP přes Ethernet, IP přes ATM atd.).
Podobné problémy potkají i produkty, aplikace a standardy jiných výrobců spoléhajících na
strukturu IP adresy podle verze 4. Půjde například o různé služby zabezpečení sítě včetně firewallů,
standardy POSIX, X-Open a další.
strana 107
Další vybrané novinky IPv6
Aby mohly aplikace využívat i všech novinek a změn v IP a navazujících protokolech, musí být
nutně provedeny i změny v API (rozhraní pro aplikační programy) jednotlivých implementací IP
protokolu. IETF nespecifikuje ve svých standardech konkrétní podoby rozhraní, jen doporučení, co by
měly obsahovat. V základním API (RFC 2553) by nemělo chybět:
- podpora adresních struktur o šířce 16 bajtů
- podpora převodu jmenných adres na číselné a naopak
- podpora konverze adresních formátů (binární, hexadecimální)
- podpora posílání multicastových paketů, přihlašování do multicastových skupin a přístup do
hlavičkových polí po kvalitu služby (značka toku a třída služby)
Rozšířené API by ve své implementaci mělo mít navíc:
- přímý přístup na IP vrstvu a k ICMP paketům
- přístup k informacím o odeslaném paketu – zdrojová adresa a síťové rozhraní
- přístup k informacím o přijatém paketu – cílová adresa a síťové rozhraní
- podporu pro zpracování doplňkových hlaviček IP
- podporu pro objevování sousedů a výpočet MTU přenosové cesty
Další zajímavou možností je využití posílání paketu o délce větší než 64 kilobajtů (na spojích,
které to umožňují). Jde o tzv. jumbogramy (dle RFC 2675, [16]), určené jedním z parametrů hlavičky
„Hop-by-Hop“, které mohou dosáhnout až 4 gigabajty. Cílem jumbogramů je zejména využít
parametrů spojové vrstvy tam, kde to nové technologie umožňují a minimalizovat režii spojenou
s hlavičkami paketů.
Pro snížení režie přenášených dat na pomalých spojích byl stanoven mechanismus komprese
IPv6, TCP a UDP hlaviček (RFC 2507). Cílem je:
- umožnit větší průchodnost linky (přenášený objem dat bude menší)
- lépe využít přenosové pásmo pro malé a tunelované pakety (kde je podíl režijních informací větší)
- snížit procento ztracených paketů na špatných linkách (pakety jsou menší, takže při konstantním
poměru chyb na přenášené bity jich bude ztraceno méně)
- snížit zpoždění pro časově citlivé aplikace, zrychlit odezvu (např. přenos hlasu, malé pakety
budou dříve přeneseny).
Jde o záležitost mezi dvěma uzly (směrovači), netýká se celé přenosové trasy. Pokud je totiž
v hlavičkách proudu dat řada stejných nebo málo se měnících informací, stačí přenášet jen jejich
změny. Jednou za čas se tedy po spoji pošle k danému datovému toku paket s plnými hlavičkami a
mezi tím se přenáší jen přírůstky a úbytky informací v hlavičkách.
Vzhledem k narůstající složitosti sítí a s přidáním mnoha povinných služeb do IPv6 protokolu
narostl i nutný objem práce nutný pro správu moderní sítě. Aby bylo vše stále zvládnutelné, došlo i
k úpravě a částečné automatizaci rutinních postupů. O záležitostech konfigurace jsem podrobněji
pojednal výše.
Ke sledování činnosti sítě je v současnosti používán protokol SNMP (ve třetí verzi), ke kterému
byly nově dodefinovány nové MIB moduly a objekty týkající se IPv6 sítí (podrobněji v RFC 2465).
Ve větší síti již nejspíše existuje SNMP Manager, který sbírá informace ze zařízení od SNMP Agentů
a monitoruje jejich provoz. Po zavedení protokolu a uzlů pracujících nad IPv6 do sítě lze aktualizací
MIB modulů spravovat a sledovat i nová IPv6 zařízení podobným způsobem, jako dříve u IPv4.
strana 108
Konfigurační soubory použité při praktickém testování - DNS
Soubor MASTER obsahuje řádky:
astra
strom
bsd
astra.ipv6
astra3.ipv6
strom.ipv6
strom3.ipv6
bsd1.ipv6
bsd2.ipv6
AX
AX
AX
IN
IN
IN
IN
IN
IN
77.88
39.39
76.27
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
08:00:20:88:f8:b7
3ffe:b80:b74:1:a00:20ff:fe88:f8b7
3ffe:b80:b74:3:a00:20ff:fe88:f8b7
3ffe:b80:b74:2:203:baff:fe05:214a
3ffe:b80:b74:3:203:baff:fe05:214a
3ffe:b80:b74:1:2a0:24ff:fe3d:aa76
3ffe:b80:b74:2:2c0:6cff:fe79:9153
Soubor/etc/named.conf obsahuje řádky:
zone "4.7.b.0.0.8.b.0.e.f.f.3.IP6.ARPA" {
type master;
file "/etc/NS/ip6.arpa";
allow-query { any; };
};
Soubor /etc/NS/ip6.arpa obsahuje řádky:
@
IN
SOA
IN
vse470.vse.cz. hostmaster.vse.cz (
2000032705 ; Serial
28800
; Refresh
7200
; Retry
604800
; Expire
86400 )
; Minimum
NS
vse470.vse.cz.
7.b.8.f.8.8.e.f.f.f.0.2.0.0.a.0.1.0.0.0.4.7.b.0.0.8.b.0.e.f.f.3.IP6.ARPA.
IN
PTR
astra.ipv6.vse.cz.
7.b.8.f.8.8.e.f.f.f.0.2.0.0.a.0.3.0.0.0.4.7.b.0.0.8.b.0.e.f.f.3.IP6.ARPA.
IN
PTR
astra3.ipv6.vse.cz.
a.4.1.2.5.0.e.f.f.f.a.b.3.0.2.0.2.0.0.0.4.7.b.0.0.8.b.0.e.f.f.3.IP6.ARPA.
IN
PTR
strom.ipv6.vse.cz.
a.4.1.2.5.0.e.f.f.f.a.b.3.0.2.0.3.0.0.0.4.7.b.0.0.8.b.0.e.f.f.3.IP6.ARPA.
IN
PTR
strom3.ipv6.vse.cz.
6.7.a.a.d.3.e.f.f.f.4.2.0.a.2.0.1.0.0.0.4.7.b.0.0.8.b.0.e.f.f.3.IP6.ARPA.
IN
PTR
bsd1.ipv6.vse.cz.
3.5.1.9.9.7.e.f.f.f.c.6.0.c.2.0.2.0.0.0.4.7.b.0.0.8.b.0.e.f.f.3.IP6.ARPA.
IN
PTR
bsd2.ipv6.vse.cz.
strana 109
Výpis síťových rozhraní, směrovacích tabulek a dostupnosti vybraných uzlů z počítačů
v testovací síti
Počítač ASTRA
# ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 146.102.77.88 netmask fffffc00 broadcast 146.102.79.255
ether 8:0:20:88:f8:b7
inet6 ::1/128
hme0: flags=2100841<UP,RUNNING,MULTICAST,ROUTER,IPv6> mtu 1500 index 2
ether 8:0:20:88:f8:b7
inet6 fe80::a00:20ff:fe88:f8b7/10
hme0:1: flags=2180841<UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500 index 2
inet6 3ffe:b80:b74:1:a00:20ff:fe88:f8b7/64
ip.atun0: flags=2200041<UP,RUNNING,NONUD,IPv6> mtu 1480 index 3
inet tunnel src 146.102.77.88
inet6 ::146.102.77.88/96
ip.tun0: flags=2200851<UP,POINTOPOINT,RUNNING,MULTICAST,IPv6> mtu 1480 index 4
tunnel dst 146.102.39.39
inet6 fe80::9266:4d58/10 --> fe80::9266:2727
ip.tun0:1: flags=2200851<UP,POINTOPOINT,RUNNING,MULTICAST,IPv6> mtu 1480 index 4
inet6 3ffe:b80:b74:3:a00:20ff:fe88:f8b7/64 -->
3ffe:b80:b74:3:203:baff:fe05:214a
# netstat -r
Routing Table: IPv6
Destination/Mask
--------------------------3ffe:b80:2:7df9::1
fe80::9266:2727
astra3.ipv6.vse.cz
strom3.ipv6.vse.cz
::/96
3ffe:b80:b74:1::/64
3ffe:b80:b74:2::/64
3ffe:b80:b74::/48
fe80::/10
ff00::/8
default
localhost
strana 110
Gateway
--------------------------fe80::2a0:24ff:fe3d:aa76
fe80::2a0:24ff:fe3d:aa76
fe80::9266:4d58
astra3.ipv6.vse.cz
astra.vse.cz
astra.ipv6.vse.cz
fe80::a00:20ff:fe88:f8b7
fe80::a00:20ff:fe88:f8b7
localhost
Flags Ref
Use
If
----- --- ------ ----UGH
1
0 hme0
UGH
1
0 hme0
UH
1
0 ip.tun0
UGH
1
0 hme0
UH
1
0 ip.tun0:1
U
1
0 ip.atun0
U
1
1 hme0:1
UG
1
0 hme0
UG
1
0 hme0
U
1
1 hme0
U
1
0 hme0
UG
1
1 hme0
UH
1
0 lo0
Počítač STROM
# ifconfig -a
inet 127.0.0.1 netmask ff000000
dmfe1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 146.102.39.39 netmask fffff800 broadcast 146.102.39.255
ether 0:3:ba:5:21:4a
inet6 ::1/128
dmfe0: flags=2100841<UP,RUNNING,MULTICAST,ROUTER,IPv6> mtu 1500 index 3
ether 0:3:ba:5:21:4a
inet6 fe80::203:baff:fe05:214a/10
dmfe0:1: flags=2180841<UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500 index 3
inet6 3ffe:b80:b74:2:203:baff:fe05:214a/64
ip.atun0: flags=2200041<UP,RUNNING,NONUD,IPv6> mtu 1480 index 4
inet6 ::146.102.39.39/96
ip.tun0: flags=2200851<UP,POINTOPOINT,RUNNING,MULTICAST,IPv6> mtu 1480 index 5
tunnel dst 146.102.77.88
inet6 fe80::9266:2727/10 --> fe80::9266:4d58
ip.tun0:1: flags=2200851<UP,POINTOPOINT,RUNNING,MULTICAST,IPv6> mtu 1480 index 5
inet6 3ffe:b80:b74:3:203:baff:fe05:214a/64 -->
3ffe:b80:b74:3:a00:20ff:fe88:f8b7
# netstat -r
Routing Table: IPv6
Destination/Mask
--------------------------3ffe:b80:2:7df9::1
astra3.ipv6.vse.cz
fe80::9266:4d58
strom3.ipv6.vse.cz
::/96
3ffe:b80:b74:2::/64
3ffe:b80:b74:1::/64
3ffe:b80:b74::/48
fe80::/10
ff00::/8
default
localhost
Gateway
--------------------------fe80::2c0:6cff:fe79:9153
fe80::2c0:6cff:fe79:9153
strom3.ipv6.vse.cz
fe80::9266:2727
fe80::2c0:6cff:fe79:9153
strom.vse.cz
strom.ipv6.vse.cz
fe80::2c0:6cff:fe79:9153
fe80::2c0:6cff:fe79:9153
fe80::203:baff:fe05:214a
fe80::203:baff:fe05:214a
fe80::2c0:6cff:fe79:9153
localhost
Flags Ref
Use
If
----- --- ------ ----UGH
1
0 dmfe0
UGH
1
0 dmfe0
UH
1
0 ip.tun0:1
UH
1
0 ip.tun0
UGH
1
0 dmfe0
U
1
0 ip.atun0
U
1
1 dmfe0:1
UG
1
0 dmfe0
UG
1
0 dmfe0
U
1
2 dmfe0
U
1
0 dmfe0
UG
1
2 dmfe0
UH
1
0 lo0
# traceroute -A inet6 2001:0718:0:1::1 (pra•ská adresa tunelu CESNET Praha-Brno)
traceroute: Warning: Multiple interfaces found; using
3ffe:b80:b74:2:203:baff:fe05:214a @ dmfe0:1
traceroute to 2001:0718:0:1::1, 30 hops max, 60 byte packets
1 bsd2.ipv6.vse.cz (3ffe:b80:b74:2:2c0:6cff:fe79:9153) 0.958 ms 0.611 ms
2 3ffe:b80:2:7df9::1 126.805 ms 119.108 ms 139.318 ms
3 tunnel-2-viagenie.ipv6.noris.de (2001:780::b) 109.856 ms 109.705 ms
4 tu2.6bone-mtp-1.ipv6.isdnet.net (3ffe:8100:102::1:5) 239.552 ms 227.073 ms *
5 2001:660:80:400d::1 294.507 ms 295.422 ms 276.778 ms
6 2001:660:80:400d::2 310.482 ms 276.324 ms 282.247 ms
7 2001:718:0:1::1 308.831 ms 297.986 ms 335.505 ms
strana 111
Počítač BSD
# ifconfig
lnc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::2c0:6cff:fe79:9153%lnc0 prefixlen 64 scopeid 0x1
inet6 3ffe:b80:b74:2:2c0:6cff:fe79:9153 prefixlen 64
inet6 3ffe:b80:b74:2:: prefixlen 64 anycast
ether 00:c0:6c:79:91:53
ep0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 146.102.76.27 netmask 0xfffffc00 broadcast 146.102.79.255
inet6 fe80::2a0:24ff:fe3d:aa76%ep0 prefixlen 64 scopeid 0x2
inet6 3ffe:b80:b74:1:2a0:24ff:fe3d:aa76 prefixlen 64
inet6 3ffe:b80:b74:1:: prefixlen 64 anycast
inet6 3ffe:b80:b74:1::1 prefixlen 64
ether 00:a0:24:3d:aa:76
media: Ethernet 10baseT/UTP
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
inet 127.0.0.1 netmask 0xff000000
ppp0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500
sl0: flags=c010<POINTOPOINT,LINK2,MULTICAST> mtu 552
faith0: flags=8002<BROADCAST,MULTICAST> mtu 1500
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
tunnel inet 146.102.76.27 --> 206.123.31.114
inet6 fe80::2c0:6cff:fe79:9153%gif0 prefixlen 64 scopeid 0x7
inet6 3ffe:b80:2:7df9::2 --> 3ffe:b80:2:7df9::1 prefixlen 128
# netstat -r
Internet6:
Destination
::
default
localhost.vse.cz
::ffff:0.0.0.0
3ffe:b80:2:7df9::1
VSE-TEST.tsps1.fre
3ffe:b80:b74::
3ffe:b80:b74:1::
3ffe:b80:b74:1::
3ffe:b80:b74:1::1
bsd1.ipv6.vse.cz
astra.ipv6.vse.cz
3ffe:b80:b74:2::
3ffe:b80:b74:2::
strom.ipv6.vse.cz
bsd2.ipv6.vse.cz
strom3.ipv6.vse.cz
astra3.ipv6.vse.cz
fe80::
fe80::%lnc0
fe80::203:baff:fe0
fe80::2c0:6cff:fe7
fe80::%ep0
fe80::2a0:24ff:fe3
fe80::a00:20ff:fe8
fe80::%lo0
fe80::1%lo0
fe80::%gif0
fe80::2c0:6cff:fe7
ff01::
ff02::
ff02::%lnc0
ff02::%ep0
ff02::%lo0
ff02::%gif0
Gateway
localhost.vse.cz
3ffe:b80:2:7df9::1
localhost.vse.cz
localhost.vse.cz
VSE-TEST.tsps1.fre
link#7
lo0
0:a0:24:3d:aa:76
link#2
0:a0:24:3d:aa:76
0:a0:24:3d:aa:76
8:0:20:88:f8:b7
0:c0:6c:79:91:53
link#1
0:3:ba:5:21:4a
0:c0:6c:79:91:53
fe80::a00:20ff:fe8
fe80::203:baff:fe0
localhost.vse.cz
link#1
0:3:ba:5:21:4a
0:c0:6c:79:91:53
link#2
0:a0:24:3d:aa:76
8:0:20:88:f8:b7
fe80::1%lo0
link#3
link#7
link#7
localhost.vse.cz
localhost.vse.cz
link#1
link#2
localhost.vse.cz
link#7
Flags
UGRSc
UGSc
UH
UGRSc
UH
UHL
USc
UHL
UC
UHL
UHL
UHLW
UHL
UC
UHLW
UHL
UGH
UGH
UGRSc
UC
UHLW
UHL
UC
UHL
UHLW
Uc
UHL
UC
UHL
U
UGRS
UC
UC
UC
UC
Netif Expire
lo0 =>
gif0
lo0
lo0
gif0
lo0
lo0
lo0 =>
ep0
lo0
lo0
ep0
lo0 =>
lnc0
lnc0
lo0
ep0
lnc0
lo0
lnc0
lnc0
lo0
ep0
lo0
ep0
lo0
lo0
gif0
lo0
lo0
lo0
lnc0
ep0
lo0
gif0
# traceroute6 strom3.ipv6
traceroute6 to strom3.ipv6.vse.cz (3ffe:b80:b74:3:203:baff:fe05:214a) from
3ffe:b80:b74:1:2a0:24ff:fe3d:aa76, 30 hops max, 12 byte packets
1 astra.ipv6.vse.cz 1.012 ms 0.847 ms 0.722 ms
2 strom3.ipv6.vse.cz 1.648 ms 1.254 ms 1.171 ms
# traceroute6 astra3.ipv6
traceroute6 to astra3.ipv6.vse.cz (3ffe:b80:b74:3:a00:20ff:fe88:f8b7) from
3ffe:b80:b74:2:2c0:6cff:fe79:9153, 30 hops max, 12 byte packets
1 strom.ipv6.vse.cz 0.937 ms 0.792 ms 0.725 ms
strana 112
2
astra3.ipv6.vse.cz
1.649 ms
1.37 ms
1.249 ms
strana 113
Text dopisu poskytovatelům připojení a mobilním operátorům
Zpracovávám diplomovou práci na téma „Internetový protokol verze 6 (IPv6) – technologické a
ekonomické aspekty“. Pro účely této práce bych se rád dozvěděl základní informaci o stavu
implementace protokolu IPv6 ve Vaší firmě jakožto poskytovatele internetového připojení.
Nevím, zda jsem ve Vaší firmě kontaktoval správnou osobu. Pokud ne, přepošlete prosím mou
otázku odpovědné osobě nebo útvaru. Děkuji.
Rád bych Vás poprosil o odpovědi (stačí stručné) na následující otázky, pokud mi je můžete
sdělit:
- Existuje ve Vaší firmě vyčleněná pracovní skupina/tým, která se IPv6 zabývá?
- V jakém časovém horizontu uvažujete o testování a implementaci protokolu IPv6 ve Vaší síti?
- V jakém časovém horizontu uvažujete o poskytování IPv6 konektivity svým zákazníkům jako
placenou službu?
- Co testování/zavedení IPv6 nyní brání?
- Co pro Vás bude impulsem (které vnější nebo vnitřní podněty) k zavedení těchto služeb?
- Které vlastnosti/služby nového protokolu považujete za nejdůležitější (které budete implementovat
nejdříve) ?
Pokud některé informace považujete za důvěrné, odpovězte mi, prosím, alespoň na zbývající
otázky. Informace získané touto použiji pouze ke zpracování mé diplomové práce bez uvedení jména
Vaší firmy ve výsledném textu a nebudu je poskytovat nikomu dalšímu.
strana 114
strana 115

Vysoká škola ekonomická v Praze Internetový protokol IP

Transkript

Podobné dokumenty

IPv6 - kdy se stane standardem?

a H - Research Center for Complex Molecular Systems and

5 - SecureNet, sro

Zavádění protokolu IP verze 6

Ipv6 v Linuxu

STARTO_2005_n. 02 (215)

zde

Z čeho se satelitní komplet skládá?

Konfigurace IPv6

akci - šedová

Vyšší vzdělání jen pro elitu?

Konfigurace počítačů se systémem Windows 7 II