IPv6

1 IPv4 hiányosságai

A következő hiányosságok indokolják a leváltását:

• Korlátozott méretű címtartomány
• Titkosított kapcsolat támogátasa
• 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, 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 a validációs eljárást.

2 IPv6 újdonságai

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

2.1 Új fejléc formá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 playload következik.

2.2 Nagyobb címtartomány

IPv6 esetén a címzési tartomány megnégyszereződött (2³²-ről 2¹²⁸-ra). A nagyobb címtartomány a NAT, megoldja a HTTP Virtualhost problémáját SSL kapcsolat esetén (ugye itt nincs 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. IP címre példa:

fe80::21c:25ff:fe97:7b1d/64 Local
2a00:1450:8007::6a Global

A címet lehet rövidíteni úgy, hogy tetszőleges darab egymást követő 0000 blokkot kihagyhatunk. A cím után lévő úgynevezett scope-ok

Speciális címtartományok:

• ::1 localhost
• ::ffff:a.b.c.d/96 IPv6 in IPv4
• fe80::/64 Link local (mivel nem létezik az IPv4-nél megszokott broadcast cím, ezért helyi címmel minden host rendelkezik, amivel el tudják érni a LAN-on egymást, hiába van globális címmel is.)
• fc80::/32 Site local (deprectad, eredetileg intranetekre lett kitalálva, de bizonyos okok miatt megszűntették, bővebben RFC3879)
• 2001::/32 Dokumentációban használt tartomány
• 2002::/32 6to4 tunneling számára lefoglalt tartomány
• ff02:: Mulitcast tartomány.
• ...

2.3 Stateless és statful IP címosztás

A dinamikus cím allokáció elméletileg egyszerűbbé vált: a kliens DHCP szerver nélkül is képes globális címet generálni magának. Ez sajnos a gyakorlati alkalmazásoknál inkább hátrányként jelenik meg. A címosztásról még lesz szó később.

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 mulitcast címzést használ broadcast helyett, ezzel csökkentve a kliensek terhelését. A gyakorlati megvalósítás nagyvonalakban: A gép el akarja érni B gépet, ezért küld egy Neighbor Solicitation üzenetet a ff02::1:ff00:0:xx:xxxx, ahol az x-el jelölt rész a B gép IP címének utolsó 24 bitje. Ezért az üzenetet csak azok a gépek kapják meg, amiknek a helyi címének utolsó 3 bájtja megegyezik x-el. A megtalált gépek belenéznek a kapott ICMPv6 üzenetbe és ha a teljes IP megegyezik az ő címükkel 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ó bekapszulázza 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".

Debian alatt így lehet kiépíteni egy 6to4 tunnelinget:

(/etc/network/interfaces fájl tartalma)
auto tun6to4
iface tun6to4 inet6 v4tunnel
address 2002:9842:D180:2::1
netmask 64
endpoint any
local 152.66.209.128
gateway ::192.88.99.1

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 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 hasonlóan az IPv4-eshez 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ó.

1. A kliens generál magának egy link-local IP címet (fe80::/64).
2. Elküld egy Router Solicitation üzenetet a minden-router multicast (ff01::2) címre.
3. 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 konfigurációt használja

O magas, M alacsony

A hosztok az IP címüket a RA üzenetben kapott prefixből generálhatják, 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. Elméleti lehetőség, gyakorlatban sosem implementálják

1. 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 szerver (ff02::1:2) címen keresztül történik.

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életlenszá

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 depracted lett, ezért nem térek ki rá.

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ás, é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 legötbb Linux terjesztés alapértelemezetten 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ásti 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ítsa úgy beállítani a routing táblát, hogy az alhálózaton belüli forgalom is routeren keresztül zajlódjon. Ezt arra használhatjuk, hogy ha vannak olyan hostok, amik másik fizikai LAN-onn 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ép 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.