globalni identifikator EUI64 - norma IEEE, jejiz cilem je pridelit kazdemu fyzickemu rozhrani v internetu jednoznacnou identifikaci. EUI64 funguje v princupu podobne jako MAC adresy (norma MAC48) - 64bitovy identifikator tvori 24bitu identifikace vyrobce, prirazena IEEE, a 40 bitu seriove cislo prirazene vyrobcem. Napr takto:
|identifikace vyrobce| seriove cislo | | AC | DE | 48 | 23 | 45 | 67 | 89 | AB |
Existuji starsi normy EUI48 a MAC48, ktere maji seriove cislo pouze 24 bitove. Pro zachovani kampatibility lze ze 48bitovych identifikatoru vytvorit 64bitove vlozenim 16bitu vyplne mezi id vyrobce a seriove cislo. Vypln je FFFE16 pro EUI48, resp. FFFF16 pro MAC48.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Verze | Trida provozu | Znacka toku | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delka dat |Dalsi hlavicka | Max. Hopu | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Zdrojova Addresa + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Cilova Addresa + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Verze - 6
Trida provozu - pozadavky toku na vlastnosti site, nema zatim presne danou semantiku
Znacka toku - identifikator proudu packetu, vice viz RFC 2460, Appendix A
Delka dat - delka paketu bez hlavicky, v oktetech
Dalsi hlavicka - stejne jako pole Protocol u IPv4, dalsi hlavicku muze byt bud rozsirena IP hlavicka nebo hlavicka protokolu vyssi urovne. Vice o rozsirenych hlavickach viz RFC 2460, Section 4.
Max. hopu - stejne jako pole TTL u IPv4
Zdrojova adresa, cilova adresa - 128bitove IPv6 adresy
Adresace, adresni prostor
Jednotlive druhy adres slouzici ruznym
ucelum jsou navzajem rozliseny pomoci prefixu.
Zatim je prirazeno asi 15 % adresniho prostoru, zbytek ceka na
pozdejsi vyuziti. Zatim definovane rozdelenii (RFC 2373):
Allocation Prefix Fraction of
(binary) Address Space
----------------------------------- -------- -------------
Reserved 0000 0000 1/256
Reserved for NSAP Allocation 0000 001 1/128
Reserved for IPX Allocation 0000 010 1/128
Aggregatable Global Unicast Addresses 001 1/8
Link-Local Unicast Addresses 1111 1110 10 1/1024
Site-Local Unicast Addresses 1111 1110 11 1/1024
Multicast Addresses 1111 1111 1/256
Individualni (unicast address) - oznacuji jedno rozhrani pripojeneho pocitace ci zarizeni, celosvetove (celointernetove) jedinecne. Adresu tvori 3 bity prefix oznacujici globalni unicastovou adresu, dalsich 61 bitu tvori prefix site (tento je dale hierarchicky clenen) a poslednich 64 bitu tvori lokalni cast adresy.
+ + TLA ID +reserved+ NLA ID + SLA ID + Interface ID +
|001| 13 bitu | 8 bitu | 24 bitu | 16 bitu | 64 bitu |
TLA - Top-level agregace, NLA - Nex-level agregace, SLA - Site-level agregace -
hierarchicke rozcleneni adresniho prostoru (napr: Bude nekolik meezinarodnich spolecnosti, ktere budou mut svoje TLA, budiu rozdavat NLA toplologicky podrizenym velkym korporacim a ISP, a ti budou alokocvat SLA ... etc. )
V IPv4 ma vetsina stroju prirazenu prave jednu adresu na kazdy interface, prip. pouze
jednu adresu na cele zarizeni. V IPv6 ma kazdy interface prirazenu nejen globalni routovatelnou adresu,
ale navic muze mit dalsi adresy:
Skupinove (multicast address) - predstavuji adresu skupiny sitovych rozhrani. Paket se skupinovou cilovou adresou bude dopraven vsem clenum skupiny. Zakladni idea multicastu - jedna informace tece kazdym kusem linky pouze jednou. Pouziva se nejcasteji pro sireni zvukoveho ci obrazoveho signalu, videokonference a podobne, tez jako nahrada broadcastovych adres v IPv4. Vice o multicastu viz prednasky doc. Matysky i sitich.
Dalsi skupinou adres jsou vyberove (anycast address) - take oznacuji skupinu sitovych rozhrani, ale paket je dopraven jen na jedno z nich (zpravidla to nejblizsi). Nemaji svuj vlastni prefix. Jsou zarazeny mezi globalni individualni adresy, lisii se pouze zpusobem zpracovani ve smerovacich algoritmech. Mozne pouziti - load balancing
NSAP, IPX - ve vyvoji, vlastne ani nikdo nevi, proc jsou soucasti IPv6 adresniho prostoru
V IPv6 se adresy zapisuji v hexadecimalni soustave, jednotlive
dvojice bajtu (ctverice sestnactkovych cislic) se pro vetsi nazornost
oddeluji dvojteckami. IPv6 adresa muze vypadat treba takto:
Dale lze v jednotlivych ctvericich vynechavat pocatecni nuly. Pokud
se vyskytne nekolik po sobe jdoucich nulovych skupin, lze je nahradit
dvojici dvojtecek. Ta se vsak v zapisu adresy smi objevit jen
jednou, aby byli zapis jednoznacny. Nasledujici zapisy jsou
ekvivalentni:
Zapis adresy je pomerne komplikovany, predpoklada se vyuziti DNS.
Pro zpetnou kompatibilitu jsou mapovany IPv4 hlavicky do IPv6 adresniho prostoru, dvema zpusoby
Dale existuji jeste specialni multicastove adresy, ktere pokryvaji napr. vsechny uzly na lokalni siti, vsechny smerovace na lokalni siti ap.
mobilita - IPv6 zajistuje moznost prechazet mezi fyzicky i logicky ruznymi sitemi bez nutnosti
rekonfigurace zarizeni, pripadne i bez preruseni spojeni. Je to zajisteno pomoci tzv. home-agentu,
kteri vedi, kde se zrovna mobilni zarizeni nachazi a znaji jeho aktualni adresu a smeruji pakety patricnym zpusebem. Pokrocilejsi algoritmus umoznuje i vynechani home-agenta, je vsak nutna podpora na druhem konci spojeni. Vice viz
IEFT - mobility in IPv6
autokonfigurace - krome DHCPv6, ktera zprostredkovava stavovou autokonfoguraci, umi IPv6 bezstavovou konfiguraci. Pomoci algoritmu Neighbor discovery 'osaha' sve okoli, od routeru ziska sitovy prefix, lokalni cast adresy vygeneruje podle EUI64 nbo z MAC adresy (nekolik pokusu pro pripad, ze adresa uz existuje). Detailni popis by byl na samostany referat :)
Slabiny - nelze nastavovat prostredi vyssich protokolu, napr. adresu DNS sreveru
Nahozeni rozhrani
Nastaveni routovani
Pomoci Tunnel skrz IPv4 infrastrukturu
Sekvence parametru pro --8<-cut-here------------------------------------------
vytvori sitove rozhrani Pomoci Tunnel skrz IPv4 infrastrukturu
BIND
Pocitac pc.domena.cz s adresou 2345:67:89AB:1:123:45FF:FE67:89AB, bude v zonovem souboru pro domenu domena.cz obsazen zaznam
DJBDNS
Zde je situace obtiznejsi - vzhledem ke vztahu autora programu k IPv6 oficialni podpora ve DJBDNS neni. Na druhou stranu je system pomerne prehledne napsany, coz dao vzniknout nekolika patchum, ktere vice ci mene do DJBDNS implementuji IPv6.
Jeden z patchu lze nalezt na
Instalace:
Pokud mate touhu pripojit se k IPv6 internetu, je v zasade nekolik moznosti:
6bone - virtualni sit, sklada se z lokalnich IPV6 siti navzajem propojenych tunely nad
IPv4 infrastrukturou. Pripojite se tak, ze pozadate nekoho s pridelenym pTLA (pseudo-TLA, prefixy
pridelene ucelem vybudovani 6bone), aby vam pridelil prefix a nakonfiguroval tunel.
Freenet6 - na adrese http://www.freenet6.net najdete
homepage projektu, ktery ma tez za cil sirit myslenku IPv6.
K siti se pripojujete pomoci specialniho klienta, ktery v pripade potreby ustavi IPv6-over-IPv4 tunel mezi vasi podsiti a Internetem.
Zapis adresy
FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
FF01:0000:0000:0000:0000:0000:0000:0101
FF01:0:0:0:0:0:0:101
FF01::101
Specialni adresy
::/128 - nedefinovaná adresa, pouziva se pri zjistovani vlastni adresy
::1/128 - zpetna vazba (loopback), nesmi se objevit v siti
::c0a8:0001 - adresa rozhrani, ktera ma zaroven IPv6 adresou
::ffff:c0a8:0002 - adresa rozhrani bez IPv6 adresy.
IPv6 a DNS
Jelikoz zapis adresy je pomerne komplikovany a adresy dlouhe, predpoklada se vyuziti DNS. V
RFC 1886 je definovan novy typ zaznamu - AAAA (typ cislo 28). Obsahuje IPv6 adresu, 8-bitovou delku prefixu a domenove jmeno podsite. Alternativou AAAA zaznamu jsou A6 zaznamy (typ cislo 38, RFC 2874). Ten obsahuje delku prefixu, IPv6 suffix a domenove jmeno podsite. Oba typy nejsou primo kompatibilni, ale existuji jednoduche prevodove mechanismy z AAAA na A6. A6 je vyrazne novejsi, avsak objevily se problemy. A6 je proto prohlasena za experimentalni a doporucuje se pouzivat starsi normu.
Dalsi vlastnosti
fragmentace - narozdil od IPv4 fragmentuje pakety pouze odesilatel. Pokud smerovac obrdzi paket vetsi, nez je MTu linky, po ktere by mel paket putovat dal, paket zahodi a posle zprvu odesilateli paketu. Ten zmensi delku paketu a zkusi to znovu. Algoritmus se nazyva Path MTu discovery, detaily viz
RFC 1981.
... vecne zeleny strom zivota.
Linux
Co je potreba do zacatku: balicek iproute2 (utilita /sbin/ip),
ping6 na ozkouseni, podpora IPv6 v jadre
ifconfig eth0 add fec0::50/64 up
nebo:
ip addr add fec0::50/64 dev eth0
route, podobne jako u IPv4:
route -A inet6 add default gw fec0::1
nebo pomoci ip
ip -6 route add ::/0 via fec0::1
ip
#!/bin/sh
#pri spravnem nastaveni vytvori IP6 over IP4 tunnel
REMOTEIP4=10.0.40.1
LOCALIP4=10.0.40.2
TUNELLPREFIX=fec0:0:0:40::/64
TUNNELIP=fec0:0:0:40::1/64
ip tunnel add tunnel1 mode sit ttl 255 remote $REMOTEIP4 local $LOCALIP4
ip link set dev tunnel1 up
ip -6 route add $TUNNELPREFIX dev tunnel1 metric 1
ip addr add $TUNNELIP dev tunnel1
--8<-cut-here------------------------------------------
tunell1, coz je virtualni tunel mezi rozhranimi
$REMOTEIP4 a $LOCALIAP4. Za tunel bude
routovat rozsah $TUNELLPREFIX a rozhrani "tunnel1" bude mit adresu $TUNNELIP.
ping6 se podivame, jestli tunnel dela to co ma, prikazem ip tunnel show vypismeme
vsechny nastavene tunely
FreeBSD
Do zacatku: je treba mit jadro z podporou IPv6. Podpora se zapina v /etc/rc.conf:
ipv6_enable="YES"
Nahozeni rozhrani:
ifconfig xl0 inet6 fec0::40/64
pripadne tak, aby ID rozhrani bylo podle normy EUI64:
ifconfig xl0 inet6 fec0::/64 eui64
Nastaveni brany:
route add -inet6 default fec0::1
#!/bin/sh
#pri spravnem nastaveni vytvori IP6 over IP4 tunnel
REMOTEIP4=10.0.40.1
LOCALIP4=10.0.40.2
TUNNELIP=fec0:0:0:40::1
ifconfig gif0 create
gifconfig gif0 $LOCALIP4 $REMOTEIP4
ifconfig gif0 inet6 $TUNNELIP prefixlen 64
DNS
pc AAAA 2345:67:89AB:1:123:45FF:FE67:89AB
Cela definice domeny domena.cz, v ktere se nachazeji dva autoritativni DNS servery (ve dvou ruznych podsitich) a jeden pocitaz, vypada asi takto
$ORIGIN domena.cz.
@ SOA ns1.domena.cz. root.ns1.domena.cz. (
2002011200 ; Serial
10800 ; Refresh
3600 ; Retry
3600000 ; Expire
86400 ; default_ttl
)
;DNS servery
NS ns1
NS ns2
;adresy pocitacu
ns1 AAAA 2345:67:89AB:1:2A0:ECFF:FE12:3456
ns2 AAAA 2345:67:89AB:2:2A0:ECFF:FE12:7890
pc AAAA 2345:67:89AB:1:123:45FF:FE67:89AB
Reverzni dotazy jsou reseny obdobne jako pro IPv4 - obrati se poradi sestnactkovych cislic v adrese a na konec se pripoji domena ip6.arpa. Napr. pro adresu
2345:67:89AB:1:123:45FF:FE67:89AB
B.A.9.8.7.6.E.F.F.F.5.4.3.2.1.0.1.0.0.0.B.A.9.8.7.6.0.0.5.4.3.2.ip6.arpa
Pro domenu domena.cz by zonovy soubor obsahoval asi takovyto zaznam:
$ORIGIN B.A.9.8.7.6.0.0.5.4.3.2.ip6.arpa.
@ SOA ns1.domena.cz. root.ns1.domena.cz. (
2002011200 ; Serial
10800 ; Refresh
3600 ; Retry
3600000 ; Expire
86400 ; default_ttl
)
;DNS servery
NS ns1
NS ns2
;reverzni zaznamy
6.5.4.3.2.1.E.F.F.F.C.E.0.A.2.0.1.0.0.0 PTR ns1.domena.cz.
0.9.8.7.2.1.E.F.F.F.C.E.0.A.2.0.2.0.0.0 PTR ns2.domena.cz.
B.A.9.8.7.6.E.F.F.F.5.4.3.2.1.0.1.0.0.0 PTR pc.domena.cz.
RAdvD
Router ADVertisment Daemon - demon, starajici se o pravidelne zasilani
tzv. "router advertisment"(ohlaseni smerovace) do site. Ohlaseni smerovace poslouchaji jine smerovace i uzly pripojene na stejne sitove segmenty jako smerovac, informaci uziji ke konfiguraci vlastniho rozhrani a konstrukci smerovacich tabulek.
wget http://v6web.litech.org/radvd/dist/radvd-0.7.2.tar.gz
tar xvzf radvd-0.7.2.tar.gz
cd radvd-0.7.2
./configure --prefix=/usr/local --sysconfdir=/etc --mandir=/usr/share/man
make
make install
./configure --prefix=/usr/local --sysconfdir=/etc --mandir=/usr/share/man
make
make install
Konfigurace (/etc/radvd.conf): nastavime, ze se ma smerovac ohlasovat na fyzickei rozhrani eth1
interface eth1 {
AdvSendAdvert on;
MaxRtrAdvInterval 30
prefix fec0:0:0:40::/64
{
AdvAutonomous on;
}
};
V konfiguraku se pravi, ze na rozhrani eth1 se ma posilat ohlaseni smerovace v intervalu 30 vterin. Dale ze na razhrani bude inzerovat prefix ten a ten, ktery muze byt za vhodnych podminek pouzit k automatickemu nakonfigurovani rozhrani nove pripojeneho uzlu.
Vice viz man radvd.conf
IPv6 a Internet
IPv6 a programovani
Filosofie sitoveho programovani se s prichodem IPv6 nemeni. Volani resolveru
gethostbyname(3)
a getservbyname(3) jak je zname z IPv4 nahrazuje nove getaddrinfo(6). O opacny preklad se stara getnameinfo(3), kterezto volani se neomezuje jen na IPv6.
Ostatni volani, jako napr. connect(), listen(),... se nemeni, je treba uvadet parametr address family INET6 misto INET..
Vice informaci viz manualove stranky.
Zdroje
RFC
Ostatni
Konec
Taky se tak tesite na IPv7 ?