IPv6

A Unix/Linux szerverek üzemeltetése wikiből
(Változatok közti eltérés)
a (olvasószerkesztés)
 
(egy szerkesztő 2 közbeeső változata nincs mutatva)
1. sor: 1. sor:
== IPv4 hiányosságai ==
+
Írta: Bendzsák András, 2010. november.
  +
  +
== Az IPv4 hiányosságai ==
 
A következő hiányosságok indokolják az IPv4 leváltását:
 
A következő hiányosságok indokolják az IPv4 leváltását:
 
* korlátozott méretű címtartomány,
 
* korlátozott méretű címtartomány,
9. sor: 9. sor:
 
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.
 
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.
 
 
== IPv6 újdonságai ==
+
== Az IPv6 újdonságai ==
 
Az alábbi lista tartalmazza az IPv6 főbb újdonságait:
 
Az alábbi lista tartalmazza az IPv6 főbb újdonságait:
 
=== Új fejlécformátum ===
 
=== Új fejlécformátum ===
38. sor: 38. sor:
 
 
 
=== IPSec fejléc támogatás ===
 
=== 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)[http://www.freebsd.org/doc/en/books/developers-handbook/ipv6.html (link)]
+
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)[http://tools.ietf.org/html/rfc4294#section-8.1 (link)]
 
 
 
=== Priorizált csomagtovábbítás jobb támogatása ===
 
=== Priorizált csomagtovábbítás jobb támogatása ===
55. sor: 55. sor:
 
 
 
=== 6to4 ===
 
=== 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 a saját gépünk publikus IP-címe. Az IP4-es csatorna másik pontja egy speciális (192.88.99.1) anycast cím, ami a legközelebbi IPv4/IPv6 gateway-re "mutat". Ez a ''mutat'' szó furcsának hangzik, de mindössze annyit jelent, hogy ha ezt az ip-t próbáljuk elérni, akkor a routing során a szolgáltatók igyekeznek a legközelebbi IPv4/IPV6 gateway felé terelni a forgalmat. Mégegyszerűbben: ha Magyarországról próbáljuk elérni ezt a címet, akkor valószínűleg egy magyar IPv4/IPv6 gateway-jel fogunk beszélgetni, míg ha Kínában, akkor egy kínai gateway-jel, hiába használjuk ugyanazt az IP-t. Bővebben erről a tunnelingről [http://www.cisco.com/web/about/ac123/ac147/ac174/ac197/about_cisco_ipj_archive_article09186a00800c830a.html ebben] a Cisco cikkben lehet olvasni.
+
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 a saját gépünk publikus IP-címe. Az IP4-es csatorna másik pontja egy speciális (192.88.99.1) anycast cím, ami a legközelebbi IPv4/IPv6 gateway-re "mutat". Ez a ''mutat'' szó furcsának hangzik, de mindössze annyit jelent, hogy ha ezt az IP-t próbáljuk elérni, akkor a routing során a szolgáltatók igyekeznek a legközelebbi IPv4/IPV6 gateway felé terelni a forgalmat. Még egyszerűbben: ha Magyarországról próbáljuk elérni ezt a címet, akkor valószínűleg egy magyar IPv4/IPv6 gateway-jel fogunk beszélgetni, míg ha Kínában, akkor egy kínai gateway-jel, hiába használjuk ugyanazt az IP-t. Bővebben erről a tunnelingről [http://www.cisco.com/web/about/ac123/ac147/ac174/ac197/about_cisco_ipj_archive_article09186a00800c830a.html ebben] a cikkben lehet olvasni.
 
 
 
Debian alatt így lehet kiépíteni egy 6to4 tunnelinget:
 
Debian alatt így lehet kiépíteni egy 6to4 tunnelinget:
80. sor: 80. sor:
 
Az IPv6 esetén másképp működik az automatikus címkonfiguráció.
 
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)
+
# 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életlenszám-generálás). (lásd később)
 
# Elküld egy Router Solicitation üzenetet a ''minden-router multicast (ff01::2)'' címre.
 
# 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:
 
# 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:
95. sor: 95. sor:
 
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''). Egyéb esetben nem egyértelmű a hálózat besorolása, forrásonként változik.
 
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''). Egyéb esetben nem egyértelmű a hálózat besorolása, forrásonként változik.
 
 
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.
+
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át. (Nyilván az IPv4-es címek is biztosítanak AAAA rekordokat, de a hosszú távon minden bizonnyal 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:
 
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:
112. sor: 112. sor:
 
 
 
== IPv6 a linuxban ==
 
== IPv6 a linuxban ==
Történelem
+
=== 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.
 
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.
 
 
 
=== Kliensoldali támogatás ===
 
=== Kliensoldali támogatás ===
Stateless hálózat
+
==== 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:
 
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:
 
 
=== Stateless hálózat DHCP szerverrel ===
+
==== 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.
 
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.
 
 
=== Stateful hálózat ===
+
==== Stateful hálózat ====
 
A helyzet ugyanez, DHCPv6 kliens telepítés, és örülés.
 
A helyzet ugyanez, DHCPv6 kliens telepítés, és örülés.
 
 
 
=== IPv6 gateway összeállítás ===
 
=== 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:
+
Ha szeretnénk, hogy a hálózatunk 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)
+
* 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, mivel garantáltan lassúbb, mint a natív IPv6.)
* egy/több Router Adverisment Daemon
+
* egy/több Router Advertisement Daemon
 
* egy/több DHCPv6 szerver
 
* 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.
 
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.
 
 
=== Router Adverisment Daemon ===
+
=== Router Advertisement 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.
+
A radvd nevű szoftver a leginkább elterjedt, ezért kezdőknek érdemes ezt használni. Telepítés után egy radvd.conf állományt kell megfelelően beállítani.
 
Itt egy példakonfig:
 
Itt egy példakonfig:
 
 

A lap jelenlegi, 2010. december 10., 01:37-kori változata

Írta: Bendzsák András, 2010. november.

Tartalomjegyzék

[szerkesztés] 1 Az 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ásának hiánya,
  • 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-re 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.

[szerkesztés] 2 Az IPv6 újdonságai

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

[szerkesztés] 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 az első 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. Ha van további fejléc, akkor az is ugyanúgy 10 szó hosszú, és annak a végén van egy flag, ami jelzi, hogy további fejléc vagy payload következik, s.í.t.

[szerkesztés] 2.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. Fontos, hogy csak egy összefüggő blokkot rövidíthetünk az egyértelműség kedvéért. Tehát például az fe80::abcd::1 rövidítés nem használható.) 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ókban használt tartomány.
2002::/32 6to4 tunneling számára lefoglalt tartomány.
2001::/32 Teredo tunneling számára lefoglalt tartomány.

[szerkesztés] 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önböztetü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 (algoritmust lásd később), és a Router Advertisment Daemon csak a (ebben az esetben szigorúan /64-es) címtartományt és a gateway(ek) IP címét szolgáltatja a hálózaton lévő hostok felé, míg stateful esetben a DHCP szerver konkrét, teljes címet ad a kliensnek.

[szerkesztés] 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)(link)

[szerkesztés] 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.

[szerkesztés] 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 multicast 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.

[szerkesztés] 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.


[szerkesztés] 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.

[szerkeszté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 a saját gépünk publikus IP-címe. Az IP4-es csatorna másik pontja egy speciális (192.88.99.1) anycast cím, ami a legközelebbi IPv4/IPv6 gateway-re "mutat". Ez a mutat szó furcsának hangzik, de mindössze annyit jelent, hogy ha ezt az IP-t próbáljuk elérni, akkor a routing során a szolgáltatók igyekeznek a legközelebbi IPv4/IPV6 gateway felé terelni a forgalmat. Még egyszerűbben: ha Magyarországról próbáljuk elérni ezt a címet, akkor valószínűleg egy magyar IPv4/IPv6 gateway-jel fogunk beszélgetni, míg ha Kínában, akkor egy kínai gateway-jel, hiába használjuk ugyanazt az IP-t. Bővebben erről a tunnelingről ebben a 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 továbbítja az IPv6-os csomagjainkat a megfelelő célcímre.

[szerkesztés] 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}. Szerencsére a konfiguráció teljesen automatikus, ezért nincs szükségünk a cím felépítésének részletes ismeretére. 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. A csatorna kiépülése teljesen automatikus, nincs szükség további konfigurációra.

[szerkesztés] 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ó. Hogy miért nem használható, arra az a válasz, hogy az RFC2462-ben ez van írva.:)

Az IPv6 esetén másképp működik az automatikus címkonfiguráció.

  1. 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életlenszám-generálás). (lásd később)
  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 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
4. 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). Egyéb esetben nem egyértelmű a hálózat besorolása, forrásonként változik.

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át. (Nyilván az IPv4-es címek is biztosítanak AAAA rekordokat, de a hosszú távon minden bizonnyal 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.

[szerkesztés] 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.

[szerkesztés] 5 IPv6 a linuxban

[szerkesztés] 5.1 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.

[szerkesztés] 5.2 Kliensoldali támogatás

[szerkesztés] 5.2.1 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:

[szerkesztés] 5.2.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.

[szerkesztés] 5.2.3 Stateful hálózat

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

[szerkesztés] 5.3 IPv6 gateway összeállítás

Ha szeretnénk, hogy a hálózatunk 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, mivel garantáltan lassúbb, mint a natív IPv6.)
  • egy/több Router Advertisement 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.

[szerkesztés] 5.4 Router Advertisement Daemon

A radvd nevű szoftver a leginkább elterjedt, ezért kezdőknek é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.

[szerkesztés] 5.5 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.

Személyes eszközök