IPv6

A lap 2010. november 11., 12:30-kori változata

1 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.

2 IPv6 újdonságai

Az alábbi lista tartalmazza az IPv6 főbb újdonságait:

2.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.

2.2 Nagyobb címtartomány

IPv6 esetén a címtér mérete 2³²-ről 2¹²⁸-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.

2.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.

2.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)

2.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.

2.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.

3 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.

3.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.

3.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.

3.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.

3.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.

4 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.

5 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.

5.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:

5.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.

5.3 Stateful hálózat

A helyzet ugyanez, DHCPv6 kliens telepítés, és örülés.

5.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.

5.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.

5.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.

@@ 1. sor: / 1. sor: @@
 == 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,