IPv6
== IPv4 hiányosságai == A következő hiányosságok indokolják az IPv4 leváltását:
- korlátozott méretű címtartomány,
- titkosított kapcsolat támogatása,
- streaming protokollok gyenge támogatása.
Az első pont a leglényegesebb és egyben legkritikusabb kérdés. A kiosztható címek fogyóban vannak, a becslések szerint 2012-ben elfogynak a kiosztható tartományok. (Igaz, ez mindig n+2 év :) )
Titkosított kapcsolatokat létre lehetett hozni IPv4 felett is, de a különböző címfordító technikák módosították az IP fejlécet, ezzel megtörve az érvényességvizsgálatot.
Tartalomjegyzék |
1 IPv6 újdonságai
Az alábbi lista tartalmazza az IPv6 főbb újdonságait:
1.1 Új fejlécformátum
Az IPv6 szabvány új típusú, szabadon bővíthető fejlécet definiált. Az IPv4-el ellentétben itt a fejléc hossza fix 10 szó, amely tartalmazza a csomag alapvető információit. Ez nagy segítség a routereknek, mert a fix fejléchossz könnyebb feldolgozást tesz lehetővé. Az első fejléc végén található egy flag, ami jelzi, hogy van-e további fejléc, vagy a payload következik.
1.2 Nagyobb címtartomány
IPv6 esetén a címtér mérete 232-ről 2128-ra nőtt. A nagyobb címtartomány feleslegessé teszi a NAT-ot, megoldja a HTTP Virtualhost problémáját SSL kapcsolat esetén (ugye itt kvázi ingyen van az IP-cím). Növeli a hálózat biztonságát, azáltal, hogy támadóknak sokkal nagyobb címtartományt kell végigpásztázni a támadható kliensek felkutatásáért. Az IPv6-os címtartományt osztályokba sorolták a hálózaton belüli érvényességük (scope szerint):
Address type Binary prefix IPv6 notation IPv4 address class ------------ ------------- ------------- ----------------- Unspecified 00...0 (128 bits) ::/128 0.0.0.0/8 Loopback 00...1 (128 bits) ::1/128 127.0.0.0/8 Multicast 11111111 FF00::/8 class D Link-Local unicast 1111111010 FE80::/10 10.0.0.0/8,172.16.0.0/12 192.168.1.0/24 Global Unicast (everything else) class A,B,C
(A címet lehet rövidíteni úgy, hogy tetszőleges darab egymást követő 0000 blokkot kihagyhatunk.) Bővebben az IPv6 címzésről az RFC4291-ben lehet olvasni.
A Global scope-on belül találkozhatunk néha speciális címtartományokkal, ezekről sem árt tudni, mert a későbbiekben lesz róluk szó:
2001::/32 Dokumentációban használt tartomány 2002::/32 6to4 tunneling számára lefoglalt tartomány. 2001::/32 Teredo tunneling számára lefoglalt tartomány.
1.3 Stateless és stateful IP-címosztás
A dinamikus IP-cím allokáció összetettebb lett IPv6 esetén. Kétféle konfigurációt különbeztetünk meg: stateful és stateless. Erről lesz szó részletesebben. ezért elöljáróban csak annyit, hogy stateless konfiguráció esetén a kliens maga választja meg, hogy pontosan milyen IP címet szeretne használni (algoritmus általában véletlenszám-generálás vagy MAC címből generálás ), és egy bizonyos Router Advertisment Daemon csak a használt (ebben az esetben szigorúan /64-es) címtartományt és a gateway(ek) IP címét, míg stateful esetben a DHCP szerver konkrét címet ad a kliensnek.
1.4 IPSec fejléc támogatás
Az IPSec kötelező eleme lett az IPv6 fejlécnek. Ez nem jelenti, hogy a csomagok automatikusan titkosítva vannak, az alkalmazásoknak támogatniuk kell a titkosítást. (AH és ESP flag)
1.5 Priorizált csomagtovábbítás jobb támogatása
Az új Flow Label fejléc segítségével jelezni tudjuk, hogy a csomag egy folyam része, és az útválasztók kiemelten tudják kezelni ezeket a csomagokat még abban az esetben is, ha azok titkosítva vannak.
1.6 Új protokoll a helyi hálózaton belüli gépek elérésre (Neighbour Discovery)
Neighbour Discovery protokoll az IP-cím MAC cím hozzárendelést valósítja meg IPv6 esetén. Előnye az ARP-vel szemben, hogy multicast címzést használ broadcast helyett, ezzel csökkentve a kliensek broadcast terhelését. A gyakorlati megvalósítás nagy vonalakban: Minden gép feliratkozik egy speciális IP címre: ff02::1:ff00:0:xx:xxxx, ahol az x-el jelölt rész a gép IP-címének utolsó 24 bitje. Tfh. A gép el akarja érni B gépet, ezért küld egy Neighbor Solicitation üzenetet a ff02::1:ff00:0:xx:xxxx címre, ami tartalmazza az A gép IP és MAC címét valamint a B gép IP címét. A multicast címen figyelő gépek belenéznek a kapott ICMPv6 üzenetbe, és ha a teljes IP megegyezik az ő címükkel (ez nyilvánvalóan csak a B gépre lesz igaz), akkor válaszolnak.
2 IPv4-IPv6 konverziók
Mivel egyik napról a másikra nem lehet a világ összes gépét átállítani IPv4-ről IPv6-ra, ezért szükség van olyan technológiákra, amik lehetővé teszik, hogy az IPv4-only hálózatból elérjük az IPv6-os címeket. Minden tunneling technológia alapja, hogy az IPv6 csomagot az IPv6/IPv4 átjáró becsomagolja egy IPv4-es csomagba, az IPv4/IPv6 átjáró pedig kicsomagolja és úgy juttatja el a címzetthez. Az átjáró nem minden esetben jelent különálló fizikai entitást a hálózaton, sok esetben a kliensek közvetlenül, automatikusan építenek ki csatornákat egymás között. Ez alapján megkülönböztetünk manuális, illetve automatikus csatornázást.
2.1 Intra-Site Automatic Tunnel Addressing Protocol
Mint a nevéből is látszik, ez csak telephelyen belül használható tunneling technológia. Helyi típusú (fe80::/64) címek képződnek egy meghatározott algoritmussal a résztvevő felek IPv4-es címéből. Nagyon ritkán használt eljárás.
2.2 6to4
Ez manuálisan és automatikusan is kiépíthető tunneling technológia. Működésének feltétele a publikus IP-cím, NAT-on keresztül egyáltalán nem működik. Cserébe minden publikus IPv4-es címhez tartozik egy globális /48-as tartomány, tehát akár egy átjáróval is el lehet látni egy nagyobb méretű, több telephelyes vállalatot IPv6-os címekkel. Az IPv6 tartomány 2002:{IPv4 cím}::/48 alakú, ahol az IPv4-es cím az átjáró publikus IP-címe. A csatorna másik pontja egy speciális (192.88.99.1) anycast cím, ami a legközelebbi IPv4/IPv6 gateway-re "mutat". Bővebben erről a tunnelingről ebben a Cisco cikkben lehet olvasni.
Debian alatt így lehet kiépíteni egy 6to4 tunnelinget:
(/etc/network/interfaces fájl tartalma) auto tun6to4 iface tun6to4 inet6 v4tunnel address 2002:{globális IPv4 címünk hexában kódolva}::1 netmask 64 endpoint any local globális IPv4 címünk gateway ::192.88.99.1
Ez létrehoz egy tunneling interfészt tun6to4 néven, ami becsomagolja az IPv6-os csomagjainkat és eljuttatja az anycast (endpoint sor) címen lévő IPv4/IPv6 átjáróhoz, ami eljuttatja az IPv6-os csomagjainkat a megfelelő célcímre.
2.3 Teredo
A Teredo tunneling működik NAT-on keresztül is, cserébe ez a legbonyolultabb az összes csatornázási technológia közül. Első körben az IPv6 csomagot nem közvetlenül az IPv4-es csomagba kapszulázza, mert ezt sok tűzfal blokkolja, hanem egy UDP csomagba. Ráadásul nem elég két pont a kommunikációhoz, szükség van egy Teredo szerverre a megfelelő IPv6 címek kiszámításához. Itt ez azért szükséges, mert helyi címből szeretnénk globálisat képezni. A következőképpen épül fel egy Teredo IPv6 cím: 2001:0000:{Teredo szerver IPv4 címe}:{16 bit flag}:{külső port}:{külső IPv4 cím}. A külső port azt az UDP portot jelenti, amelyre a NAT-nak fordítania kell a kommunikációt. A flagek részletezése megtalálható az 4380-as RFC-ben. A többi mező értéke triviális. Teredo tunneling konfigurálásához Debian esetén a miredo csomagot kell feltelepíteni.
2.4 IPv6 címkonfiguráció
Az IPv6-os címeket az IPv4-eshez hasonlóan két részre lehet bontani: alhálózati maszk (network mask) és egy egyéni azonosító (host-id). IPv6 esetén az ajánlott alhálózati maszk /64. Ettől el lehet térni -- és el is szoktak bizonyos esetekben -- de a kisebb, illetve nagyobb prefixű hálózatokban a stateless konfiguráció nem használható. (Stateless konfigurációról később)
Az IPv6 esetén másképp működik az automatikus címkonfiguráció.
- A kliens (azaz, aki IP címet szeretne) generál magának egy link-local IP-címet (fe80::/64). Ez a generálás történhet MAC címből ([ EUI64 http://tools.ietf.org/search/rfc4291#appendix-A], illetve tetszőleges más algoritmussal is (véletlen szám generálás). (lásd később)
- Elküld egy Router Solicitation üzenetet a minden-router multicast (ff01::2) címre.
- A router(ek) válaszként küld(enek) egy Router Advertisment üzenet, ami tartalmaz M (Managed) és O (Other) flaget, ami szerint a kliens különböző eljárásokat követ:
- O és M flag alacsony
- A hálózaton nem található DHCP szerver, a kliens az RA üzenetben kapott címtérből generál magának egy IP címet (mac címből (EUI-64), vagy véletlenszám-generálással).
- O magas, M alacsony
- A hostok az IP-címüket a RA üzenetben kapott prefixből generálhatják (mint az előző pontból), de a további beállításokat (pl. DNS) a DHCP szervertől kapják
- O és M flag magas
- A kliens a globális IP-címét és az egyéb beállításokat is a DHCP szervertől kapja
- O alacsony, M magas
- A kliens a DHCP szervertől kap IP-címet, de kiegészítő paramétereket (pl DNS szerverek) nem. Elméleti lehetőség, gyakorlatban sosem implementálják
- A DHCPv6 szerverrel a kommunikáció hasonló módon zajlik, mint a IPv4 esetében, annyi különbséggel, hogy a kommunikáció broadcast üzenetek lehetőségének hiánya miatt minden DHCPv6 szerverrel a (ff02::1:2) címen keresztül történik.
A O és M flag alacsony típusú hálózatokat hívja a szakirodalom stateless konfigurációnak, tehát DHCPv6 szerver egyáltalán nem található a hálózaton belül. Stateful konfiguráció esetén a DHCPv6 szerver allokál címet kliensnek (O és M flag magas).
A folyamatból kitűnik, hogy van egy hatalmas hibája a stateless konfigurációnak: az RA üzenet nem tartalmazza a DNS szerver címét. DNS nélkül egy munkaállomás nem alkalmas semmilyen hálózati munkára, tekintve az IPv6-os címek megjegyezhetetlen hosszára. (Nyilván az IPv4-es címek is biztosítanak AAAA rekordokat, de hosszútávon létrejövő IPv6-only hostokkal mi lesz?) Tehát mindenféleképpen szükséges egy DHCPv6 konfigurálása a hálózaton.
Stateless konfigurációnál az IP-cím host-id részét (az utolsó 64 bit) valahonnan "generálja" a kliens. Két elterjedt módszer van:
- EUI64
- A hálózati interfész MAC címéből generálódik a következőképpen: {MAC cím első 24 bitje}:fffe:{MAC cím második 24 bitje}.
- Véletlen szám
- Az operációs rendszer véletlenszerűen generálja a host-id-t.
Az eredeti koncepció szerint az EUI64 címgenerálás volt az ajánlott, ezt követi a Windows XP, a legtöbb Linux disztribúció és a MAC OS X is. Ez a módszer felvet bizonyos adatvédelmi kérdéseket: a MAC címből generált host-id világszinten egyedi lesz a MAC cím miatt (mobil eszközöknél biztosan), ezért például a tartalomszolgáltók a felhasználókat követni tudják, bárhonnan érik el a világhálót. Ezért a Microsoft a Windows Vista és 7 esetében véletlenszám-generátorral allokál magának host-id-t. Ennek a módszernek az a hátulütője, hogy megnehezíti a kliensek azonosítását és a privilégiumok hozzárendelését pusztán a munkaállomás IP-címe alapján.
3 DNS IPv6 esetén
Bekerült egy új AAAA rekord, ami a névhez tartozó IPv6 címet tartalmazza. Pl:
foo IN AAAA 2001:1:42:1::2a AAAA 2001:2:42:1::2a
Létezik még egy A6 rekord, ami mivel elavult lett, ezért nem térek ki rá. Természetesen a DNS szervernek nem kell IPv6 felett kommunikálnia a klienssel, hogy az AAAA rekordokat szolgáltatassa.
4 IPv6 a linuxban
Történelem Az IPv6 támogatás 1996-ban jelent meg a linux kernelben. Sajnos humán erőforrás hiányában a kernelben lévő implementáció elavulttá vált a 2000-es évek elejére. Ezen próbált változtatni az USABI projekt, ami third party patchet kínált a kernelhez, ami tartalmazta a legújabb IPv6 specifikációt. A patchset olyan méretűre duzzadt az idők folyamán, hogy lehetetlenné vált a 2.4.x-es ágba a beolvasztása. Ezen segített a 2.5.x-es ág megjelenése segített, ezért a 2.6.x már megfelelő IPv6 támogatással rendelkezik.
4.1 Kliensoldali támogatás
Stateless hálózat Amennyiben a kernel tartalmaz IPv6 támogatást és stateless hálózathoz csatlakozunk, akkor semmit sem kell csinálni, a statless konfigurációnál leírt módon kapunk IP tartományt, default gatewayt, stb. és generálunk magunknak címet. Amennyiben szeretnénk erről az autokonfigurációról lebeszélni a rendszert (mert mondjuk szervert üzemeltetünk), azt következő úton tehetjük meg:
4.2 Stateless hálózat DHCP szerverrel
Amennyiben IPv6 DNS szervert is szeretnénk kapni (tehát a felhasználók 99,999%-ához tartozunk), akkor szükség lesz egy dhcpv6 kliensre. A legtöbb Linux terjesztés alapértelmezés szerint nem tartalmaz dhcpv6 klienst, tehát telepítenünk kell. A telepítés után elindul egy daemon, ami folyamatosan figyeli a bejövő RA üzeneteket és lekéri a megfelelő beállításokat (esetünkben DNS szerver, de sok minden mást is tud, pl NTP) a DHCPv6 szervertől.
4.3 Stateful hálózat
A helyzet ugyanez, DHCPv6 kliens telepítés, és örülés.
4.4 IPv6 gateway összeállítás
Ha szeretnénk, hogy a hálózatunkon képes legyen IPv6-os címeket kiosztani, akkor a következő dolgokkal kell rendelkeznünk:
- IPv6 képes végpont a szolgáltatónktól, vagy legalább egy publikus IPv4 cím, hogy rendes tunnelinget tudjunk kiépíteni. (Megjegyzés: utóbbit labor környezeten kívül máshol nem ajánlom, garantáltan lassabb mint natív IPv6 esetében)
- egy/több Router Adverisment Daemon
- egy/több DHCPv6 szerver
Amennyiben szeretnénk teljes mértékben leépíteni a meglévő IPv4-es hálózatunkat, akkor konfigurálni kell egy DNSv6 proxyt és egy IPv6-IPv4 translatort.
4.5 Router Adverisment Daemon
A radvd nevű szoftver a leginkább elterjedt, ezért érdemes ezt használni. Telepítés után egy radvd.conf állományt kell megfelelően beállítani. Itt egy példakonfig:
interface eth0 {
AdvSendAdvert on; AdvManagedFlag off; AdvOtherConfigFlag on; MinRtrAdvInterval 5; MaxRtrAdvInterval 15; prefix 2001:9842:D180::/64 { AdvOnLink on; AdvAutonomous on; };
};
Az állomány struktúrája hasonlít az ISC DHCP szerver struktúrájához. Minden hálózati csatolót külön kell konfigurálni interface blokkok segítségével. Az AdvSendAlert engedélyezi az RA üzenetek kiküldését, az AdvManagedFlag és a AdvOtherConfigFlag opciók a már tárgyalt M és O flagekenek felel meg. Jelen esetben csak az O flag on, mivel nem szeretnénk a DHCP szervernek delegálni a címosztást. A MinRtrAdvInterval és a MaxRtrAdvInterval az RA üzenetek gyakoriságát szabályozza, nincs komoly jelentősége. A következő prefix blokkban a hálózatunk prefixének deklarációja látható. Az AdvOnLink opciónak nagyon fontos szerepe van: off beállítás esetén tájékoztatja a klienseket, hogy nem minden IP-cím található meg a hálózaton, ezért állítsák be úgy a routing táblát, hogy az alhálózaton belüli forgalom is routeren keresztül történjen. Ezt arra használhatjuk, hogy ha vannak olyan hostok, amik másik fizikai LAN-on vannak, akkor azok a gépek is elérhetőek maradjanak. Az AdvAutonomous egy engedélyező flag, ami megengedi a klienseknek, hogy saját címet generálhassanak maguknak.
4.6 DHCPv6 szerver
DHCPv6 szervernek szintén a WIDE-féle implementáció az ajánlott , ez jelenleg a legelterjedtebb és ehhez érhető el a legjobb közösségi támogatás. Amennyiben stateless konfigurációt használunk, a konfigfájl a következő lesz: option domain-name-servers 2002:9842:d180::1; Azt hiszem itt minden magáért beszél.
Ha DHCP szerverre szeretnénk bízni az IP-cím osztást akkor a következő példakonfig nyújt segítséget: option domain-name-servers 2002:9842:d180::1; host teszt{
duid 00:01:00:06:13:6a:4a:40:00:0c:29:26:0a:49; address 2001:9842:d180::0:1:0:1 infinity;
}; interface eth0 {
address-pool pool1 3600;
}; pool pool1 {
range 2001:9842:d180::2:0:1 to 2001:9842:d180::2:0:400 ;
}; Az első sor változatlan, utána egy teszt nevű gépet definiálunk a DUID-val és az IP-címmel. Az utána szereplő két blokk a nem regisztrált gépeknek szánt tartományt definiálja, ami a pool1 nevet viseli. Ezeknek a neveknek semmi köze a kliensek DNS címéhez, csupán a hivatkozást segíti a konfigurációkor.