Rozšíření adresového prostoru bylo prvotní motivací pro vznik Internetového protokolu nové generace. Návrh IPv6 přichází s výrazným rozšířením délky adresy. Oproti adresám v IPv4, kde je možno teoreticky zaadresovat přibližně 4 miliardy zařízení, disponuje protokol IPv6 adresou o délce 128 bitů.

To znamená, že je možné do Internetu připojit cca 3,4×10³⁸ zařízení. Takové číslo je poměrně obtížně představitelné. Po přepočtu by na každého člověka na Zemi připadalo několik triliónů adres.

Další přirovnání můžeme odvodit z následujícího algoritmu. Kdybychom každou vteřinu přidělovali jednu síť s délkou prefixu 40bitů, vystačí nám tato zásoba na 35 tisíc let (pro 32b. je to 136 let). Můžeme tedy považovat celkové množství adres za skutečně neomezené.

Pro pořádek zmíníme, že IPv6 adresa se zapisuje prostřednictvím třiceti dvou hexa čísel oddělených po čtveřicích dvojtečkou. V rámci zápisu je možné použít následující zjednodušení – varianty si ukážeme na příkladu adresy

2001:067c:122­0:0004:0000:0000:93e5:03­94.

Použít je možné všechny výše uvedené zápisy vyjadřující vždy stejnou adresu. Existuje i zápis ve tvaru číselných dvojic oddělených dvojtečkami (tj. 20:01:06:7c:1­2:20:00:04:00:00:00:00:9­3:e5:03:94), ale jedná se o spíše ojedinělý formát, se kterým se můžete setkat například v definicích MIB stromů.

Dalším typickým parametrem uváděným společně s IPv6 adresou je délka prefixu. Ekvivalentem pro prefix v IPv4 světě je maska podsítě. V případě IPv6 se již nepoužívá zápis v podobě bitového pole definujícího část adresy, která patří do síťové a hostitelské části, ale výlučně se používá notace definující délku síťové masky. Tu pak zapisujeme za symbol „/“ číselným uvedením počtu bitů síťové části. Výsledná adresa může vypadá následovně:

Typy adres

Stejně jako v protokolu IPv4, i v IPv6 je definováno několik typů adres. Následující tabulka shrnuje hrubé rozdělení základních typů IPv6 adres, se kterými se dnes můžeme setkat. Pro přehlednost jsou rovněž uvedeny odpovídající ekvivalenty z IPv4 světa.

Jak vidíte, v IPv4 byly některé typy adres zrušeny bez náhrady, a naopak některé nové typy přibyly. Do tabulky nejsou zahrnuty adresy používané pro potřeby přechodových mechanismů. Budeme si jim věnovat v samostatném dílu.

Link-Local

Zcela revoluční novinku představují Link-Local adresy. Jedná se o speciální typ adresy, kterou má každé IPv6 zařízení automaticky nakonfigurováno již od okamžiku aktivování rozhraní. Link-Local adresa se na některých zařízeních nedá zrušit ani změnit. Pakety využívající Link-Local adresu se mohou šířit pouze v rámci jednoho síťového segmentu, tj. k prvnímu směrovači.

Link-local adresy v systému poznáme velice jednoduše podle jejich úvodní magické kombinace fe80::. Plná Link-Local adresa může vypadat následovně:

fe80::20c:29ff:fec9:92df/64

Mezi speciality těchto adres mimo jiné patří, že na jednom zařízení adresa často mívá na různých rozhraních totožnou hodnotu. Zpravidla musíme při komunikaci prostřednictvím této adresy doplnit za symbol % jméno nebo nějakou identifikaci rozhraní, kterým chceme komunikovat.

Samotná existence Link-Local adres umožnila přesunout velkou část komunikace, zejména z oblasti signalizace, právě na tuto úroveň. Například:

• Veškerá signalizace na lokální úrovni – objevování sousedů (ND), oznamování směrovače (RA), detekce duplicitních adres (DAD), atd. V IPv6 byste například marně hledali protokol ARP. Veškerá funkcionalita odpovídající tomuto protokolu je přesunuta do signalizačních ICMPv6 zpráv, které využívají komunikaci výhradně na Link-Local adresách.
• Směrovací protokoly jako například OSPFv3/RIP-NG. Příjemným důsledkem je, že odpadá nutnost konfigurovat spojovací sítě mezi jednotlivými rozhraními směrovačů. Stačí příslušné rozhraní směrovače přiřadit do OSPFv3 nebo RIP-NG procesu, a tím je konfigurace spojovací sítě mezi směrovači hotová.

Pokud je to ale jen trochu možné, použijí se pro komunikaci mezi uzly právě Link-Local adresy. I přes skutečnost, že Link-Local adresy mají dosah pouze na lokální síti, mohlo by se zdát, že nevyžadují nějakou zvláštní pozornost z hlediska zabezpečení. Je ovšem třeba mít na paměti, že prostřednictvím Link-Local adres je možné komunikovat v jakékoliv sítí. Pokud jste si například do /etc/host.allow vložili záznam

ALL : [FE80::]/64 : allow

tak určitě neděláte dobře. Tímto nabídnete své služby sousedům ve všech sítích, kde se vyskytnete, tj. i všem zloduchům připojeným například ve stejné WiFi síti. Komunikace na Link-Local adresách by rovněž měla být blokována na úrovni korporátního firewallu. Ne že by jejich prostřednictvím dokázal někdo komunikovat, ale správně podvržená Link-Local adresa, zapsaná jako zdrojová adresa v paketu, může velice dobře posloužit útočníkovi. Koncový systém by měl také automaticky zahazovat všechny pakety, které mají ve zdroji Link-Local adresu a kde je cílová adresa nastavena jako globální.

Broadcast

V IPv6 již nenajdeme všesměrové (broadcast) adresy. Veškerá komunikace, pro kterou bylo dříve využíváno všesměrového vysílání, je bez výjimky přesunuta do multicastu.

Unique-Local, Site-Local

Další skupinu tvoří IPv6 adresy, které asi dokážeme nejlépe přirovnat k privátním adresám z IPv4 světa. V IPv6 jsou odpovídající náhradou tzv. unikátní lokální adresy (ULA, Unique Local IPv6 Unicast Addresses, RFC 4193). Stejně jako privátní IPv4 adresy smí být použity pouze v rámci omezené lokality a nesmí se směrovat v globálním Internetu. Na rozdíl od privátních IPv4 adres mají jednu stěžejní výhodu. Algoritmus vytváření síťového prefixu je tvořen tak, aby byl unikátní. Prefix se vytváří prostřednictvím algoritmu, do kterého vstupuje datum a MAC adresa vámi spravovaného zařízení. Tímto by měla být zajištěna světová unikátnost prefixu, který jste si takto vytvořili. Kdo by i přesto měl pochybnosti o unikátnosti jeho ULA adres, může využít registraci prostřednictvím databáze spravované v rámci webu SixXS.

Na některých i novějších systémech a zejména v literatuře můžete narazit na tzv. Site-Local adresy. Oproti ULA adresám nejsou unikátní a dalo by se říci, že zcela přesně odpovídají privátním adresám tak, jak jsme je znali z IPv4. Používání těchto adres se ukázalo jako slepá ulička a Site-Local adresy byly výnosem v podobě RFC 3879 v roce 2004 zrušeny. Adresový blok fec0::/10 příslušící těmto adresám by se již neměl více používat.

Multicast, Anycast

Skupinovým (multicast) a výběrovým (anycast) adresám se budeme podrobněji věnovat v samostatném dílu, proto je pro tuto chvíli odbudeme pouze konstatováním, že existují.

Global

Zbývajícím typem adres jsou globální (Global) adresy. Jsou to nejdůležitější adresy, prostřednictvím kterých komunikují uzly v globálním Internetu.

Síťová část globálních adres a struktura sítí

Struktura a dělení globálních IPv6 adres

V rámci globálního Internetu byla snaha rozdělit adresy tak, aby při čtení zleva doprava co nejvíce odpovídala fyzické struktuře sítí. Na nejvyšší úrovni jsou bloky adres obhospodařovány organizací IANA. Ta přiděluje bloky jednotlivým regionálním registrátorům (RIR, tj. RIPE NCC, ARIN, APNIC, AFRINIC, LACNIC). Regionální registrátoři následně přidělují bloky tzv. lokálním registrátorům (LIR), kteří pak připojují sítě koncových zákazníků. Každá taková síť má pak mít přidělen vlastní prefix, který je možno dále dělit. Předpokládá se, že každý koncový zákazník (uživatel) by měl mít přidělenou síť s délkou 48 bitů, tedy pro vnitřní adresaci zůstává 16 bitů. Prakticky tedy může vytvořit 65535 koncových sítí s délkou prefixu 64 bitů. Stále se vedou diskuse zda přidělovaní prefixu délky 48 bitů není pro běžné uživatelé plýtváním a tedy prozatímní draft tuto délku upravuje na 56 bitů. Takto je možno vytvořit 256 podsítí, kde lze v každé adresovat 2⁶⁴ zařízení, což by měl být pro koncové zákazníky stále dostačující počet.

Domácí sítě

Stále otevřenou záležitostí je přidělování adres menším anebo domácím sítím. V současné době je praxe taková, že síti je přidělena zpravidla jedna IPv4 adresa a na této adrese je zapojeno přímo koncové zařízení, nebo prostřednictvím NATu je možné připojit další zařízení na privátních adresách. Z hlediska IPv6 je existence NATu něco nepřijatelného. Vzniká tedy otázka, jakým možným způsobem přidělovat adresy pro domácí sítě. Jestli krabička, kterou máte doma v komoře, bude L2 přepínač, L3 směrovač nebo dokonce nějaká forma IPv6 NATu.

Poměrně triviální řešení, které známe z IPv4 světa, se v IPv6 značně komplikuje. Poskytovatel, který by se rozhodl implementovat IPv6 pro takto připojené zákazníky, stojí v současné době před velkým problémem. Může zvolit některé z následujících řešení, přičemž žádné z nich není zcela bezproblémové. Věc se navíc komplikuje skutečností, že po přechodnou dobu, která asi nebude úplně krátká, je nutno počítat s paralelním provozováním stávající IPv4 infrastruktury s mechanizmem NATu. Problém se dá řešit třemi cestami.

IPv6-NAT: Již jsme uvedli, že NAT by měl být v IPv6 sítích zcela vyloučen. Existují snahy uvést NAT i do života IPv6, ale zatím pouze v rovině návrhů. Fungující, a v praxi použitelnou implementaci, bychom tak jak tak zatím zřejmě hledali marně. Jistým kompromisním řešením by mohlo být bezstavové mapování ULA adres na veřejné adresy, jak navrhuje draft-mrw-nat66. Implementace je dostupná zatím v experimentální podobě pro Linuxový netfilter. Pro použití v tomto režimu by muselo dojít ještě k jistým úpravám. Z hlediska aktuálních trendů je tato forma řešení zcela na okraji zájmu.

Zařízení v režimu L3 směrovače: V takovém případě by pro potřeby IPv4 provozu domácí směrovač zajišťoval překlad adres prostřednictvím NATu a pro IPv6 provoz by se stal plnohodnotným L3 směrovačem. Zde ovšem vzniká otázka, jak informovat domácí směrovač o prefixu vnitřní sítě a obráceně, na základě čeho vznikne na straně ISP směrovací záznam odkazující na sítě za domácím směrovačem. K tomuto účelu se používá speciální volba DHCPv6 s názvem prefix delegation (RFC 3633), která informuje domácí zařízení o sítích, které má použít pro vnitřní adresaci. Podrobněji požadavky specifikuje  draft-ietf-v6ops-ipv6-cpe-router a zatím není zcela jasné zda bude výrobci domácích směrovačů a ISP obecně akceptován. Problémem také zůstává problematika vzniku směrovacích záznamů na straně poskytovatele. V počtu tisíců koncových uživatelů (zákazníků) se již nemusí jednat o zcela zanedbatelný problém a mechanismus musí být nějakým způsobem automatizován. Draft draft-yeh-dhc-dhcpv6-prefix-pool-opt předpokládá, že směrovač poskytovatele (PE) si takový záznam vytvoří na základě obsahu komunikace mezi DHCPv6 serverem a DHCPv6 agentem. Zatím neznám zařízení, které by tuto volbu podporovalo. Jedná se jednoznačně o nejsložitější formu připojování domácích sítí, nicméně zatím masově převažuje názor, že tato forma představuje to „čisté“ a „správné“ řešení.

Zařízení v podobě L2 přepínače: Toto řešení se opírá o propojení připojovacího portu providera a lokální sítě na linkové úrovni, tedy přepínače (bridge, switche). Na první pohled triviální řešení bez nutnosti vytváření dalších standardů. Není ovšem zcela bez problémů. Samotný fakt, že v sítích bude muset po nějakou dobu koexistovat protokol IPv6 společně s protokolem IPv4, dostává toto řešení prakticky mimo hru. Uvažovat by se dala varianta, kdy by na L2 úrovni byly předávány (bridgovány, switchovány) pouze pakety patřící IPv6 protokolu. Tato varianta je teoreticky jednoduše použitelná, nicméně zatím na trhu neexistuje zařízení, které by takovou funkcionalitu poskytovalo. Další nezanedbatelnou nevýhodou tohoto řešení je to, že veškerá vaše zařízení jsou ve stejné podsíti společně se sousedovým laptopem, kávovarem, myčkou atd. Tímto vnášíme do sítě nové bezpečnostní problémy, které však nejsou neřešitelné. Úvahy o fungování domácích zařízení se tímto směrem zatím příliš neubírají.

Pokud se podíváme na nastíněné možnosti, patrně už žádné další principielní varianty nevymyslíme. K dnešnímu dni bohužel prakticky neexistuje standardizovaný a obecně použitelný postup pro připojování domácích sítí. Bude tedy nutné ještě nějakou chvíli počkat. Jako poněkud problematické se jeví, že i kdyby výrobci domácích směrovačů chtěli dnes podporu IPv6 do svých zařízení implementovat, tak v podstatě neví jak. Pokud si přece jen takové pokrokové zařízení koupíte, tak je velice obtížné určit, co vlastně ona podpora IPv6 deklarována na obalu vlastně znamená a zda takové zařízení za rok, či dva nebudete muset tak jak tak vyhodit a koupit si jiné. Případným zájemcům doporučuji prostudovat dokumentaci k některým zařízením dostupnou na stránkách SixXS. Zjistíte, že pod pojmem podpora IPv6 si každý výrobce představuje něco jiného. Certifikace v podobě základního stříbrného či zlatého IPv6 Ready loga v tomto směru příliš mnoho nepomůže, protože kritéria pro tento typ zařízení nejsou součástí certifikace. Nutná je certifikace pro DHCPv6. Realita je taková, že podpora domácích zařízení se tak dneska soustředí zpravidla na statické IPv6 směrování a případně na podporu přechodových mechanizmů. Jen v některých případech je k dispozici podpora delegace prefixu z DHCPv6 a  – nutno říci, že zpravidla v silně experimentální podobě.

Multihoming

Další komplikace s přidělováním sítí souvisí se zcela protilehlým koncem klientského spektra IPv6 sítí, a to s velkými korporacemi. Původní myšlenka hierarchického členění adres podle topologie sítě je jistě velice dobrá. Zásadním způsobem redukuje počet záznamů ve směrovacích tabulkách díky možností agregace jednotlivých prefixů. Tento koncept poněkud narušuje otázka multihomingu, tedy připojení sítě k více poskytovatelům. V protokolu IPv4 se plnohodnotný multihoming prakticky bezvýhradně řeší prostřednictvím přidělení vlastního autonomního systému (AS) a přičleněním speciálního adresového prostoru (PI – provider independend address). Napojení do globálního směrování Internetu pak zajišťují směrovače připojující síť k více poskytovatelům prostřednictvím protokolu BGP.

Protokol IPv6 měl ambice řešit problém multihomingu zcela jinou koncepcí tak, aby byla zachována podmínka hierarchické struktury sítí. Jistou naději poskytuje protokol Shim6 (Site Multihoming by IPv6 Intermediation), nicméně v současné době se jedná pouze o návrh s jedinou, spíše experimentální implementací (http://www.o­penhip.org/). A bude zcela jistě trvat dlouhou dobu, než bude protokol prakticky použitelný.

Vzhledem k tomu, že se za celou dobu nepodařilo najít nějaká přijatelná a funkční řešení, nezbylo tedy nic jiného, než zcela pragmaticky sáhnout po již ověřeném mechanizmu v podobě přidělování PI adres. Každá taková PI síť ovšem znamená samostatný směrovací záznam na úrovní globálních směrovacích tabulek v BGP, čímž se ovšem opět narušuje původně zamýšlený koncept optimalizovaného směrování. K problematice multihomingu se ještě vrátíme v příštím dílu.

Koncové sítě

Zbývající část adresy je určena pro identifikaci jednotlivých zařízení v koncových sítích. Je zvykem téměř bez výjimky přidělovat sítě s délkou prefixu 64 bitů. Tím se dělí IPv6 adresa na dvě části. Síťová část (horních 64 bitů) a hostitelská část (Host ID, nebo Interface ID) v dolních 64 bitech. Někomu se může jevit takovéto dělení poněkud nehospodárné. Mít k dispozici pro adresaci 64bitů, v rámci jednoho síťového segmentu, je skutečně přepych, nicméně toto rozdělení se již ustálilo a jakékoliv snahy použít pro koncové sítě prefix jiné délky než 64 bitů naráží na celou řadu praktických komplikací. Pokud tedy nemáte extrémně dobrý nepoužívejte prefixy jiné délky než 64 bitů, byť v sítí budete mít připojená jen dvě nebo tři zařízení.

Hostitelská část adresy – Host ID, Interface ID

Dříve než se pustíme do rozboru hostitelské části adresy, dovolím si malý exkurz do minulosti. Možná si někdo vzpomene na doby sítí na bázi protokolu IPX/SPX, kde nebylo potřeba se zatěžovat mechanizmem adresace koncových stanic. Do PC se vložila síťová karta, která se připojila do sítě. Tím bylo veškeré konfigurování hotovo. Adresa síťové vrstvy se jednoduše odvodila od linkové adresy síťové karty a bylo vystaráno. V případě IPv4 pochopitelně takové zjednodušení nepřipadalo v úvahu, jakožto důsledek poměrně malého prostoru pro adresaci zařízení v koncových sítích. V případě IPv6 je vše jinak. Pro hostitelskou část adresy je vyhrazen prostor celých 64 bitů. Takto velký adresový prostor nám umožňuje realizovat věci dosud nevídané.

Adresy IPv6 EUI-64

Prvotní návrhy předpokládaly odvození hostitelské části adresy z „něčeho“, co už adresu má. Naprosto přirozeně se k tomuto nabízelo použít již existující adresy linkové vrstvy, tedy MAC adresy. Namapovaní 48 bitů (délka MAC adresy) do 64 bitů nepředstavuje žádný problém. Mírnou modifikací IEEE EUI-64 algoritmu vznikl IPv6 EUI-64 algoritmus pro tvorbu hostitelské části adresy.

Mapování IPv6 EUI-64 adres

Jak vidíte na obrázku, dopředný i zpětný převod je jednoduše proveditelný bez většího mentálního úsilí, a vztah mezi oběma adresami je zřejmý na první pohled. Tento velice jednoduchý a praktický způsob tvorby IPv6 adres začal narážet na závažný problém v podobě ochrany soukromí. Díky tomu, že hostitelská část adresy se nemění, ať už se pohybujete se svým laptopem nebo mobilním telefonem kdekoliv, je velice snadné vystopovat nejen to, které konkrétní zařízení k příslušné službě přistupovalo, ale i z které sítě. Tento způsob tvorby adresy je implementován a ve výchozím stavu aktivován ve většině operačních systémů (MAC OS, Linux, FreeBSD) a zařízení.

Privacy Extensions

Dočasné IPv6 adresy v systému Win XP

Otázky ochrany soukromí nutně vedly k úvahám, jakým myslitelným způsobem zkomplikovat jednoduchou identifikaci koncových zařízení. Vzniklo řešení „Privacy Extensions“ (plným názvem Privacy Extensions for Stateless Address Autoconfiguration in IPv6, který s dovolením budu zkracovat) nejdříve v podobě RFC 3041, později nahrazeným RFC 4941. Princip „Privacy Extension“ spočívá v nahodilém generování hostitelské části IPv6 adresy. Takto vytvořené adresy se v pravidelných intervalech obměňují a vznikají nové. Typicky je nová adresa vygenerována jednou za den až týden a v systému se udržuje po dobu 10 dnů. Zcela bez nadsázky můžeme říct, že IPv6 adresa koncového zařízení vzniká nazdařbůh, nedá se dopředu predikovat a průběžně se mění – každá vlastnost sama o sobě je dostatečně děsivá. Pro většinu správců je pochopitelně nepřijatelné, aby se v sítí vyskytovala zařízení, o kterých vůbec nemá tušení, co jsou zač a nijak je nedokáže identifikovat. Privacy Extensions mají ve výchozím stavu aktivovány všechny systémy z produkce Microsoftu určené uživatelům (Windows 7, Vista, XP). Ve většině dalších systémů (Mac OS, Linux, FreeBSD) je možno Privacy Extensions aktivovat v konfiguraci. Obrázek zachycuje IPv6 adresy v systému Windows XP po týdenním nepřetržitém provozu.

Jelikož identifikace koncových zařízení v sítí je poměrně stěžejní pro udržení pořádku, je nutno se s tímto problémem vhodně vypořádat. Jednou z možností je deaktivování Privacy Extansions přímo na klientských systémech. Tím však vystavujeme naše uživatele narušení jejich soukromí, a rekonfigurace všech zařízení, která se v síti vyskytnou, je zkrátka nereálná. Lze rovněž očekávat, že časem bude toto rozšíření, po vzoru Microsoftu, ve výchozím stavu aktivováno na většině systémů.

Dočasné IPv6 adresy v systému v průběhu jednoho týdne

Jistou formu řešení představuje shromažďování obsahu tabulek cache sousedů (Neighbor Cache) na směrovači. Jedná se o obdobu ARP tabulky z IPv4. Stejně jako ARP také cache sousedů obsahuje linkovou adresu (MAC adresu) a jí odpovídající IPv6 adresu, či spíše IPv6 adresy. Pokud už máme vazbu IPv6 – MAC adresa, jsme schopni z této vazby vyvodit nějaké další souvislosti. V případě, že v síti podporujeme autentizaci prostřednictvím IEEE 802.1X, můžeme tyto údaje propojit například s autentizačními údaji radius serveru. Následující graf zachycuje obsah cache sousedů získané právě popsaným způsobem. Jak můžeme vidět v průběhu jednoho týdne v jednotlivých časových intervalech PC komunikuje s využitím různých IPv6 adres.

Náhled na IPv6 adresy v systemu MetaNAV

Nástrojů, které by řešily tuto problematiku, zatím není mnoho. Jedním z nástrojů, který je možné použít, je systém MetaNAV. V pravidelných intervalech načítá ze směrovače obsah cache sousedů prostřednictvím SNMP a údaje ukládá do databáze. Tuto je možno následně propojit s nějakým vlastním systémem anebo využít přímo webového rozhraní nabízeného systémem MetaNAV.

Další možnosti je využití nástroje, který dokáže analyzovat obsah signalizačních protokolů. Vzhledem k tomu, že veškerá signalizace se odehrává na úrovni multicastu, není problém tyto informace odposlechnout jakýmkoliv zařízením připojeným do lokální sítě. V IPv4 světe je mnohými správci oblíben nástroj jménem arpwatch. Jistou alternativou pro  IPv6 je NDPMon. Vývoj projektu ovšem od roku 2009 stagnuje a systém je zatížen poměrně velkým množstvím chyb. S jistým úsilím je však použitelný.

Manuální konfigurace IPv6 a další možnosti

Výše uvedené možnosti konfigurace IPv6 adresy byly určeny spíše pro klientské stanice. Stejně jako v IPv4 zůstává zachována možnost manuální konfigurace. Tuto možnost využijeme zejména na serverech. Zde právě můžeme použít zjednodušený zápis IPv6 adresy, kdy posledních 32 bitů adresy zapíšeme ve tvaru IPv4 adresy. Otevírá se zde rovněž pole pro tvůrčí správce. Do hostitelské části IPv6 adresy počítače svého oblíbeného kolegy nebo šéfa můžete zakomponovat nějaký užitečný vzkaz, poselství nebo upozornění pro ostatní. Několik příkladu pro inspiraci:

2001:0fa:fff0:fe00:dead:face:c156:7b93
2001:15c0:6603:add:bad:dad:c0b0:1
2001:15c0:6603:0:fade:b00b:babe:1
2001:968::c0f:fee

Tak vidíte, že IPv6 je přece jen zábavný a fe80::c00l.

Zatím jsme zcela pominuli možnosti konfigurace adres prostřednictvím DHCPv6 a nebo s využitím kryptografické metody prostřednictvím SeND. Tyto možnosti probereme v samostatném dílu věnovaném problematice autokonfigurace koncových zařízení a bezpečnosti.

Závěr

Potřeba rozšíření adresového prostoru byla prvotní motivaci vzniku celého protokolu IPv6. V tuto chvílí lze říci, že tento požadavek byl bezezbytku splněn jednou pro vždy. Hierarchizace adres potenciálně umožňuje mnohem efektivnější správu směrovacích informací na globální úrovni. Tato výhoda je do jisté míry narušována konceptem přidělování PI adres. Bohužel nadále neustálený zůstává mechanismus přidělování adres domácím sítím. Nejedná se ani tak o problém samotného adresového prostoru, jako spíše o postupné ustálení standardů a technologií.

V rovině koncových sítí přináší IPv6 zcela nové možnosti adresace koncových systémů. Za největší změnu lze považovat tvorbu IPv6 adres na klientských systémech za použití Privacy Extensions. Lze očekávat, že po vzoru Microsoftu bude toto rozšíření využívat většina klientských systémů. Tato inovace jistým způsobem komplikuje správu lokálních sítí, a do budoucna zřejmě výrazným způsobem změní úhel pohledu a zvyklosti při správě sítě.