IPv6-cím

Az internetprotokoll 6-os verziójú cím (IPv6-cím) egy hexadecimális számsorozat, mellyel egy számítógép hálózati interfészét – vagy más hálózati csomópontot – lehet azonosítani IPv6-alapú hálózatokban.

Az IP-címek arra szolgálnak, hogy egyedileg azonosítsák egy gazdagép egy hálózati interfészét, azaz egy a hálózatban található gép, valamelyik hálózati kártyáját ha egynél több hálózati kártya van behelyezve. Lehetővé téve ezzel az IP-csomagok irányítását a gépek között. A routoláshoz a cél- és forrás-címek az IP-csomag fejlécének megfelelő mezőiben találhatóak.

Az IPv6 az internet első címzési infrastruktúrájának, az internetprotokoll 4-nek (IPv4) az utódja. Az IPv6 128 bites címeket használ, szemben az elődje 32 bites címeivel, ezzel nagymértékben megnövelve a lehetséges címtartományt.

Az IPv6-cím felbontása kettes számrendszerbeli alakjára

IPv6-os címosztályok

Az IPv6-címek osztályozása az alapvető hálózati címzési és útválasztási módszertanok szerint történik: unicast (egyedi) címzés, anycast címzés, és multicast (többes-)címzés.

• Az unicast címek egy egyedi hálózati interfészt azonosítanak („egyescímzés”). Az internetprotokoll az unicast címre küldött csomagokat a megfelelő egyedi interfésznek továbbítja.
• Az anycast címek egy csoport interfészhez vannak hozzárendelve, amelyek általában különböző csomópontokhoz tartoznak. Egy anycast címre küldött csomagot a tag-interfészek egyike kapja csak meg, jellemzően a legközelebbi hoszt (az útválasztási protokoll távolságfogalma szerint). Az anycast címeket nem könnyű felismerni, ugyanolyan formájúak, mint az unicast címek, csak abban különböznek, hogy a hálózat több pontján vannak jelen. Majdnem minden unicast cím használható anycast címként is.
• A multicast címeket szintén több hoszt használja, amelyek a multicast cél státuszukat a hálózati útválasztók közti multicast elosztási protokollban való részvételükkel biztosítják. A multicast címre küldött csomag minden olyan interfészhez eljut, amely csatlakozott a megfelelő multicast csoporthoz.

Az IPv6 nem valósítja meg a szórási címzést (broadcast). A szórás hagyományos szerepét átvette a többescímzés minden csomópont kapcsolati szintű (link-local) többescímzési csoportja (ff02::1). Azonban ennek az összes csomópont csoportnak a használata nem ajánlott, és a legtöbb IPv6-protokoll dedikált kapcsolati szintű többescímzésű csoportot használ annak érdekében, hogy ne „zavarja” a hálózat összes interfészét.

Címformátumok

Az IPv6-címek 128 bitből állnak. A címek több típusra oszthatóak a fő címzési és útválasztási módszertanok alkalmazásai szerint: unicast, multicast és anycast hálózatkezelésre. Mindhárom esetben több címformátum azonosítható a 128 címbit logikai bitcsoportokra osztásával, és szabályok felállításával ezen bitcsoportok értékeinek a speciális címzési tulajdonságokkal való társításához.

Az unicast címek formátuma

Az unicast és anycast címek jellemzően két logikai részből állnak: egy 64 bites útválasztáshoz használt hálózati előtagból, és egy 64 bites interfész azonosítóból, ami a hoszt hálózati interfészét azonosítja.

Általános unicast címformátum

bit	48	16	64
mező	útválasztási előtag	alhálózat ID	interfész azonosító

A hálózati előtag a cím nagy helyiértékű 64 bitjében található. Az ajánlott kiosztás végfelhasználóknak 48 bitnyi routolási előtag. Ebben az esetben 16 bit alhálózati azonosító áll rendelkezésére a hálózati adminisztrátornak alhálózatok meghatározására. A 64 bites interfész azonosító lehet automatikusan generált az interfészek MAC-címeiből a módosított EUI-64 formátum szerint, adhatja DHCPv6 szerver, lehet automatikusan véletlenszerűen megállapított, vagy kézzel megadott.

A kapcsolati szintű cím is az interfészazonosítón alapul, de a hálózati előtagja más formátumú.

Kapcsolati szintű (link-local) címformátum

bit	10	54	64
mező	előtag	nullák	interfész azonosító

Az előtag mező értéke a bináris 1111111010. Ezt 54 nulla követi, aminek következtében a kapcsolati szintű címeknél az összes hálózati előtag ugyanaz, ezért nem routolhatóak. (Az első 64 bit hexadecimálisan leírva: fe80:0000:0000:0000:, vagy fe80:0:0:0:, röviden pedig fe80:: – ez utóbbi esetben a :: rövidítés már nem alkalmazható az interfész azonosítónál.)

A multicast címek formátuma

A multicast címek formátuma az alkalmazástól függően több specifikus szabálytól függ.

Általános multicast címformátum

bit	8	4	4	112
mező	előtag	flgs	sc	csoport azonosító

Az előtag a bináris 11111111 értéket tartalmazza minden multicast címnél. Jelenleg 3 flag bit van definiálva a 4-ből az flgs mezőben, a legnagyobb helyiértékű flag bit későbbi használatra van fenntartva. A 4 bites sc (scope, hatókör) mező jelzi, hogy a cím hol érvényes és egyedi.

Solicited-node multicast címformátum

bit	8	4	4	79	9	24
mező	előtag	flgs	sc	nullák	egyesek	unicast cím

Az előtag és sc mezők a bináris 11111111 és 0010 értékeket tartalmazzák. A solicited-node multicast címek a csomópont unicast vagy anycast címeiből számíthatóak. A solicited-node multicast cím az unicast vagy anycast cím utolsó 24 bitjének a multicast cím utolsó 24 bitjébe másolásával állítható elő.

Unicast-előtag alapú multicast címformátum

bit	8	4	4	4	4	8	64	32
mező	előtag	flgs	sc	res	riid	plen	hálózati előtag	csoportazonosító

A kapcsolati hatókörű multicast címek hasonló formátumúak.

Ábrázolás

Az IPv6-címeket hexadecimális alakban ábrázoljuk, nyolc négyes csoportra osztva. Minden csoport 16 bitet, azaz két oktetet ábrázol. A csoportokat kettősponttal választjuk el (:). Egy példa IPv6-címre:

2001:0db8:85a3:0000:0000:8a2e:0370:7334

A hexadecimális számjegyek nem kis-nagybetű érzékenyek, de ajánlott a kisbetűs írásmódot használni.

A teljes ábrázolást több módon lehet egyszerűsíteni, elhagyva bizonyos részeket.

Bevezető nullák

A bevezető nullákat el lehet hagyni egy csoportban, de minden csoportban szerepelnie kell legalább egy hexadecimális számjegynek. Példa:

2001:db8:85a3:0:0:8a2e:370:7334.

Nullák egymást követő csoportja(i)

Kettő vagy több egymást követő, csak nullákból álló csoportot le lehet egyszerűsíteni egy üres csoportra két egymást követő kettősponttal (::). Ezt az egyszerűsítést egy címben csak egyszer lehet elvégezni, mivel több előfordulás többértelművé tenné a címet. Ha több ilyen cserét lehetne elvégezni, a legtöbb csoportot érintőt kell egyszerűsíteni; ha a két csoport egyforma hosszú, balról az elsőt. A példabeli cím ezek alapján tovább egyszerűsítve:

2001:db8:85a3::8a2e:370:7334

A localhost visszacsatolási (loopback) cím (0:0:0:0:0:0:0:1) és az IPv6-os nem specifikált cím (0:0:0:0:0:0:0:0) rövidítve ::1 és ::.

Ponttal elválasztott decimális jelölés

Az IPv4-ről IPv6-ra való átállás közben tipikus a kevert címzésű környezet. Erre a célra egy speciális jelölést vezettek be, hogy az IPv4-mapped és IPv4-kompatibilis IPv6-címek utolsó 32 bitjét az IPv4-címeknél megszokott módon írjuk. Például az ::ffff:c000:280 IPv4-mapped IPv6-címet általában így írjuk: ::ffff:192.0.2.128, világosan jelezve az IPv4-címet, ami le lett képezve IPv6-címmé.

Hálózatok

Egy IPv6-hálózat folytonos IPv6-címekből álló, kettő hatvány méretű címtartományokat használ. A cím elején levő bitek egyformák az adott hálózatban található összes hosztnál. Ezt hálózati címnek, avagy útválasztási előtagnak hívjuk.

A hálózati címtartományokat a CIDR jelölés szerint írjuk. Egy hálózatcím három részből áll: a címtartomány első (nullákra végződő) címéből, ezt perjel követi, majd egy decimális érték, ami az előtag bitben megadott hosszát adja meg. Például a 2001:db8:1234::/48 hálózat kezdő címe 2001:db8:1234:0000:0000:0000:0000:0000, utolsó címe pedig 2001:db8:1234:ffff:ffff:ffff:ffff:ffff.

Egy interfészcím útválasztási előtagját közvetlenül jelezhetjük a címben a CIDR jelölés segítségével. Például a 2001:db8:a::123 című interfész, ami a 2001:db8:a::/64 alhálózathoz csatlakozik a következőképpen jelölhető: 2001:db8:a::123/64.

Címtartomány-méretek

A címtartomány méretét egyszerűen egy perjel után megadott decimális számmal jelöljük, ami a hálózati előtag hosszát adja meg. Így nem kell megadnunk a tartományban szereplő címeket. Például egy 48 bites előtaggal rendelkező blokk jelölése /48. Ez a blokk 2^{128 – 48} = 2⁸⁰ címet tartalmaz. Minél kisebb a hálózati előtag, annál nagyobb a címtartomány: egy /21-es blokk nyolcszor akkora mint egy /24-es.

Literális IPv6-címek mint hálózati erőforrás azonosítók

A kettőspont (:) karakterek az IPv6-címekben összeférhetetlenek az erőforrás-azonosítók (például URI-k és URL-ek) kialakult szintaxisával. A kettőspont hagyományosan a hosztcímet zárja le a portcím előtt. Az egyértelműség miatt a literális IPv6-címeket szögletes zárójelbe tesszük az ilyen erőforrás-azonosítókban, például:

http://[2001:db8:85a3:8d3:1319:8a2e:370:7348]/

Ha az URL portcímet is tartalmaz, akkor:

https://[2001:db8:85a3:8d3:1319:8a2e:370:7348]:443/

Literális IPv6-címek mint UNC-elérésiút-nevek

A Microsoft Windows operációs rendszerekben az IPv4-címek érvényes azonosítók az UNC-útnevekben. Azonban a kettőspont nem megengedett karakter az UNC-nevekben, így az IPv6-címek nem szerepelhetnének bennük. Emiatt a Microsoft implementált egy átírási algoritmust, ami az IPv6-címeket doménnévként ábrázolja, és így lehet használni UNC-útnevekben is. Ehhez a Microsoft regisztrálta az ipv6-literal.net másodszintű domént az interneten. Az IPv6-címeket hosztnévként vagy aldoménként lehet átírni ebben a névtérben, a következőképpen:

2001:db8:85a3:8d3:1319:8a2e:370:7348 → 2001-db8-85a3-8d3-1319-8a2e-370-7348.ipv6-literal.net

Ezt a jelölést automatikusan feloldják a Microsoft szoftverek egyetlen DNS-kérés nélkül. Ha az IPv6-cím zónaindexet is tartalmaz, hozzá lesz fűzve a címhez egy „s” karakter után:

fe80--1s4.ipv6-literal.net

IPv6-címek hatóköre (scope)

Minden IPv6-címnek – kivéve a nem specifikált címet (::) – van egy hatóköre, ami megadja hogy a hálózat mely részében érvényes.

Az unicast címzési osztályban a kapcsolati szintű (link-local) és a visszacsatolási (loopback) címeknek kapcsolati szintű (link-local) a hatókörük, ami azt jelenti, hogy csak a közvetlenül csatlakoztatott hálózaton (kapcsolaton) használhatóak. Minden más címnek – ideértve az egyedi helyi címeket (ULA) is – globális (vagy univerzális) hatóköre van, ami azt jelenti, hogy globálisan routolhatóak, és használhatóak más globális hatókörű címekhez való csatlakozáshoz bárhol, vagy kapcsolati szintű hatókörrel rendelkező címekhez a közvetlenül csatlakoztatott hálózatban.

Az anycast címek hatóköre az unicast címekre vonatkozó szabályokkal analóg.

A multicast címeknél a cím második oktetjének legkisebb helyiértékű bitje (ff0s::) adja meg a hatókört, azaz a hálózat azon részét, ahol a multicast cím hirdetve van. A jelenleg definiált hatókörök a következőek: interfész szintű (0x1), kapcsolati szintű (0x2), admin szintű (0x4), telephely szintű (0x5), szervezeti szintű (0x8), és globális (0xe). A 0x0 és 0xf értékek későbbi használatra vannak fenntartva.

IPv6-címtér

Általános felosztás

Az IPv6-címek kiosztását az IANA felügyeli, az Internet Architecture Board és az Internet Engineering Steering Group döntése alapján. Az IANA fő funkciója a nagy címtartományok regionális internetregisztrátoroknak (RIR-eknek) való kiosztása, amelyek tovább osztják az ISP-knek és más helyi regisztrátoroknak. Az IANA tartja karban az IPv6-címtér allokációjának hivatalos listáját 1995 decembere óta.

Csak a teljes címtér 1/8-a van kijelölve az interneten való használatra. Az IPv6 címtér nagyobb része jövőbeni használatra van fenntartva. A hatékony útvonal-összefogás (route aggregation) biztosítása, és így az internetes útválasztási táblák méretének csökkentése miatt a 2000::/3-as címtér a RIR-ekhez nagyméretű, /23 – /12 blokkokban kerül.

A RIR-ek kisebb blokkokat osztanak a helyi internetregisztátoroknak, akik tovább osztják a címeket a felhasználók felé. Ezen blokkok mérete tipikusan /19 és /32 között mozog. Végül a végfelhasználók általában /48 – /56 méretű blokkokat kapnak. Egy speciális eset van, ez a szolgáltatófüggetlen címtér, amit a RIR-ek közvetlenül a végfelhasználóknak osztanak.

A globális unicast címek kiosztása megtalálható a RIR-ek oldalain és több más weboldalon.

Az IPv6-címeket sokkal nagyobb blokkokban osztják a különböző szervezeteknek, mint az IPv4-címeket: az ajánlott kiosztás egy /48-as tartomány, ami 2⁸⁰ címet tartalmaz, így 2⁴⁸-szor (avagy 7,2·10¹⁶-szor) nagyobb mint egy /8-as IPv4-tartomány, ami a legnagyobb kiosztott méret volt az IPv4-es címeknél. A teljes címkészlet azonban elegendő lesz a belátható jövőben, mivel 2¹²⁸ (vagy 3,4·10³⁸) egyedi IPv6-cím van.

Minden RIR feloszthatja a /23-as tartományait 512 db /32-es blokkra, amelyekből jellemzően minden internetszolgáltató kap egyet. Az internetszolgáltató feloszthatja a /32 tartományát 65 536 /48-as részre, amiből jellemzően minden ügyfél kap egyet. Végül az ügyfelek 65 536 /64-es alhálózatot hozhatnak létre a kapott /48-as tartományukon belül, ahol is minden alhálózatban a teljes IPv4-címtér négyzetének megfelelő mennyiségű cím van. (Az IPv4-címtér csak 2³², vagy másként 4,3·10⁹ méretű.)

A teljes címtérnek szándékosan csak egy nagyon kis töredékét fogják ténylegesen használni. A hatalmas címtér biztosítja, hogy szinte mindig lesz elérhető cím, ami szükségtelenné teszi a hálózati címfordítást (NAT). A címfordítást egyre elterjedtebben használják az IPv4-alapú hálózatokban a címek elfogyásának késleltetésére, megkerülésére.

Fenntartott anycast címek

A legkisebb cím minden alhálózati előtagnál (ahol az interfészazonosító végig nulla) az „alhálózati router” (subnet-router) anycast cím számára van fenntartva. Az alkalmazások ezt a címet használhatják, ha az egyik elérhető útválasztót akarják elérni. Az erre a címre küldött csomagokat csak egy router kapja meg.

Minden /64-es alhálózat-előtagnál a 128 legmagasabb cím az anycast címek számára van fenntartva. Ezen címek interfész-azonosítójának az első 57 bitje általában 1-re van állítva, amit egy 7 bites anycast azonosító követ. A hálózati előtagoknak, beleértve az alhálózatokat is 64 bit hosszúnak kell lenniük. Így az univerzális/lokális bit-nek 0 kell hogy legyen, jelezvén hogy a cím nem globálisan egyedi. A 7 legkisebb helyiértékű bitjén 0x7e értéket tartalmazó cím a mobil IPv6 otthoni ágensek anycast címe. A 0x7f érték (minden bit 1) nem használható, fenntartva későbbi használatra. Ebből a tartományból nincs több hozzárendelés, így a 0x00 – 0x7d értékek is a fenntartottak közé tartoznak.

Speciális címek

Az alábbiakban azokat a címeket mutatjuk be, amelyek speciális jelentéssel bírnak az IPv6-ban.

Nem specifikált cím

• ::/128 — a végig nullákból álló címet nem specifikált címnek hívjuk (hasonlóan az IPv4 0.0.0.0 címéhez). Ezt a címet soha nem szabad interfészhez rendelni. A szoftverek ideiglenesen használják, mielőtt az alkalmazás megtanulta volna a hosztja megfelelő forráscímét egy kapcsolatfelépítéshez. A routerek nem továbbíthatnak nem specifikált címet tartalmazó csomagokat. Az alkalmazások figyelhetnek egy vagy több konkrét interfészen bejövő kapcsolatokra várva, ami az aktív kapcsolatok listájában konkrét IP-címekkel látszik (amit kettősponttal elválasztva egy portszám követ). Ha a nem specifikált cím látszik a listában, az azt jelenti, hogy az alkalmazás az összes elérhető interfészen várja a bejövő kapcsolatokat.

Alapértelmezett átjáró

• ::/0 — az alapértelmezett unicast átjárócím (megfelel a 0.0.0.0/0 címnek – vagyis az alhálózati maszk: 0.0.0.0 – IPv4-ben).

Helyi címek

• ::1/128 — a visszacsatolási (loopback) cím egy unicast localhost cím. Ha egy alkalmazás csomagokat küld erre a címre, az IPv6 stack visszahurkolja ezeket ugyanarra a virtuális interfészre (ugyanúgy, mint a 127.0.0.1 cím esetében IPv4-nél).
• fe80::/10 – a kapcsolati szintű (link-local) előtaggal rendelkező címek csak egy kapcsolaton belül egyediek és érvényesek. Csak a helyi hálózat egy szegmensén belüli kommunikációra használhatóak, vagy pont-pont kapcsolatokban. Ebben a tartományban csak egyetlen alhálózat van allokálva (54 nulla bit az előtagban), így a tényleges alakja fe80::/64. A kis helyiértékű 64 bit az interfészazonosító, ami általában a MAC-címből generált módosított EUI-64 formátumú. A kapcsolati szintű cím kötelező minden IPv6-képes interfészen, akkor is, ha van globálisan routolható unicast címe. A kapcsolati szintű címek lehetővé teszik a hosztok címzését globálisan routolható előtag nélkül is, amit a helyi internetregisztrátortól/ISP-től szerezhetünk be. Más szóval az alkalmazások támaszkodhatnak ezeknek a címeknek a létezésére akkor is, ha nincs IPv6-routing. Az útválasztók a link-local címeket nem továbbítják. Ezek a címek körülbelül az IPv4 automatikus címkonfiguráció tartományának felelnek meg (169.254.0.0/16).

Egyedi helyi címek

• fc00::/7 — az egyedi helyi címek (unique local address, ULA) helyi, intranetes kommunikációra valóak. A tartományt az RFC 4193 definiálja. A privát IPv4 címeknek felelnek meg. Csak egy csoport együttműködő site között routolhatóak (analóg módon a 10/8, 172.16/12 és 192.168/16 IPv4 tartományokkal). Egy hosztnak lehet egyedi helyi címe és globális címe is (sőt, akár több mint egy globális címe) egyszerre. A címnek tartalmaznia kell egy 40 bites pszeudo-véletlen számot az útválasztási előtagjában, hogy minimalizálja a címütközések kockázatát abban az esetben, ha site-ok összeolvadnak vagy véletlenül kiroutolódnak csomagok az internetre. A címek korlátozott, helyi használata ellenére a hatókörük globális, azaz várhatóan globálisan egyediek. Az fc00::/7 tartomány két /8-as csoportra oszlik:

• fc00::/8 – a használata még nincs meghatározva. Vannak javaslatok arra, hogy valamelyik címkiosztási szervezet kezelje ezt a tartományt, de még nem fogadta el ezeket az IETF.

• fd00::/8 – ebben a blokkban az érvényes /48-as előtagot egy véletlenszerűen generált 40 bites szám segítségével képezzük. Az RFC 4193 javaslatokat tesz arra, hogyan generáljuk ezt a véletlen azonosítót. Ezeket a címeket kioszthatjuk és használhatjuk külső engedély nélkül. Emiatt nem garantáltan globálisan egyediek, globális DNS-bejegyzésük nem megengedett. Ha egy hosztnak kommunikálnia kell egy külső, internetes hoszttal, akkor szüksége van globális IPv6-címre is a helyi címe mellett. Az egyéb helyi eszközöknek (például nyomtatók, hálózati eszközök) nincs szüksége globális címre, elég az ULA.

Előre meghatározott multicast címek

Az ff00::0/12 multicast címek fent vannak tartva, és nem rendelhetőek multicast csoportokhoz:

• ff01::1 és ff02::1 — minden csomópont multicast címek. Az összes IPv6 csomópontot azonosítják 1-es (interfész-lokális), vagy 2-es (kapcsolati szintű) hatókörben.
• ff01::2, ff02::2, és ff05::2 — minden útválasztó multicast címek. Az összes IPv6 útválasztót azonosítják 1-es (interfész-lokális), 2-es (kapcsolati szintű), vagy 5-ös (site-local) hatókörben.
• ff02::1:ff00:0/104 — solicited-node multicast címek. A csoportazonosító legkisebb helyiértékű 24 bitjébe az interfész unicast vagy anycast címének legkisebb helyiértékű 24 bitje kerül. Ezek a címek lehetővé teszik a kapcsolati szintű címek feloldását a szomszéd felderítő (NDP) protokoll segítségével a hálózaton anélkül, hogy a helyi hálózat összes csomópontját „zavarnák”. Egy hosztnak kötelező csatlakoznia egy solicited-node multicast csoporthoz minden konfigurált unicast vagy anycast címével.

IPv4-IPv6 átmenet

• ::ffff:0:0/96 — IPv4-mapped IPv6 cím. Kevés kivétellel ez a címtípus lehetővé teszi az IPv4 feletti szállítási rétegbeli protokollok transzparens használatát IPv6 hálózati API-kban. Így a szerverprogramoknak csak egy nyitott figyelő socketre van szükségük az IPv4 vagy IPv6 protokollt használó kliensek felől jövő kapcsolatok kezeléséhez.
• ::ffff:0:0:0/96 — IPv4-fordított címekhez használt előtag, amit az állapotmentes IP/ICMP fordító (SIIT) protokoll használ.
• 64:ff9b::/96 — a „jól ismert” („Well-Known”) előtag. Ezen előtaggal rendelkező címek az automatikus IPv4/IPv6 fordításban használatosak.
• 2002::/16 — ez az előtag a „6to4” címzéshez használatos. Ehhez az IPv4 192.88.99.0/24 tartományából is tartozik cím.

Speciális célú címek

A IANA allokált egy úgynevezett „Sub-TLA ID” címtartományt, ami 64 hálózati előtagból áll a 2001:0000::/29 – 2001:01f8::/29 tartományban. Ebből a blokkból három hozzárendelés történt:

• 2001::/32 — a Teredo tunneling-hez használatos (ami az IPv6-átmeneti mechanizmusok egyike),
• 2001:2::/48 — a Benchmarking Methodology Working Group (BMWG) kapta meg, az IPv6 benchmarkingjához (hasonlóan a 198.18.0.0/15 blokkhoz, ami az IPv4 benchmarkinghoz lett kiosztva),
• 2001:10::/28 — ORCHID (Overlay Routable Cryptographic Hash Identifiers): nem routolható IPv6 címek, amelyeket kriptografikus hasítófüggvény-azonosítókként használnak.

Dokumentáció

• 2001:db8::/32 — ezt az előtagot a dokumentációkban használjuk. Ezeket a címeket kell használni mindenhol, ahol példa IPv6 címek szerepelnek, vagy hálózati modelleket írunk le (megfelelően a 192.0.2.0/24, 198.51.100.0/24, és 203.0.113.0/24 IPv4 címeknek).

Állapotmentes automatikus címkonfiguráció (SLAAC)

Rendszerindításkor egy csomópont automatikusan hozzárendel egy kapcsolati szintű címet minden IPv6-képes interfészéhez, még akkor is, ha vannak kézzel beállított vagy DHCPv6-on kapott globálisan routolható címek az interfészeken. Ezt függetlenül és mindenféle előzetes konfiguráció nélkül teszi az állapotmentes automatikus címkonfiguráció (SLAAC) segítségével, a szomszéd-felderítő protokoll (Neighbor Discovery Protocol) egy komponense segítségével. Ennek a címnek az előtagja fe80::/64.

Továbbá a hoszt automatikusan készíthet magának routolható unicast címet is, ha a router válaszol az útválasztó-kérelmezés (router solicitation) kérésére.

Ezen címek alsó 64 bitje módosított EUI-64 formátumú, 64 bites interfész-azonosító. Ez az azonosító általában közös az összes egyazon interfészen automatikusan konfigurált címnél, aminek megvan az az előnye, hogy csak egy multicast csoporthoz kell csatlakozni a szomszédfelderítés miatt. Ehhez a multicast cím használatos, amit az ff02::1:ff00:0/104 előtag és a cím 24 legkisebb helyiérékű bitjének összekombinálásából kapunk.

Módosított EUI-64

A 64 bites interfész-azonosítót leggyakrabban a 48 bites MAC-címből képezzük. A MAC-címet (például 00:1D:BA:06:37:64) először 64 bites EUI-64-re konvertáljuk az FF:FE bitsorozat középre való beillesztésével: 00:1D:BA:FF:FE:06:37:64. Ha ebből az EUI-64 alakból képezzük az IPv6-címet, még módosítani kell: az univerzális/lokális bit jelentését invertáljuk (ez a hetedik legnagyobb helyiértékű bit), így az 1 jelentése lesz univerzális (ami rendesen lokálisat jelent, a MAC-címek pedig mindig univerzálisan egyediek). Tehát például a 2001:db8:1:2::/64 előtagból képzett IPv6-cím 2001:db8:1:2:021d:baff:fe06:3764 lesz, ahol az aláhúzott nibble-ben elhelyezkedő U/L bit invertálva van 0-ról 1-re.

Az U/L bit módosításának oka az, hogy kézzel kiosztott címek esetében használhatjuk a 2001:db8:1:2::1/64 alakot a kevésbé elegáns és nem intuitív 2001:db8:1:2:0200::1/64 helyett. Ha kézzel állítjuk be a kapcsolati szintű címeket, a változtatás oka még szembetűnőbb: használhatjuk az fc80::1 rövid címet a kényelmetlen fc80:0:0:0:0200::1 helyett. Univerzális csak a „gyárilag beégetett” MAC-cím lehet, a rendszergazda által, manuálisan adminisztrált mindig lokális.

Kettős cím észlelése

Az unicast IPv6-címek interfészhez rendelésénél történik egy belső teszt a cím egyediségének felderítésére az ICMPv6 Neighbor Solicitation és Neighbor Advertisement üzenetei segítségével (ICMPv6-üzenettípus: 135 és 136). Amíg folyamatban van a cím egyediségének ellenőrzése, addig a cím próba (tentative) állapotban van.

A csomópont csatlakozik a próbacímével a solicited-node multicast csoporthoz, és neighbor solicitations üzeneteket küld, amelyekben a próbacíme a célcím és a nem specifikált cím (::/128) a forráscím. Egyben csatlakozik az ff02::1 minden hoszt multicast címhez is, így képes lesz fogatni a Neighbor Advertisements üzeneteket.

Ha a csomópont kap neighbor solicitation üzenetet a saját próbacímével mint célcím, akkor a címe nem egyedi. Ugyanez igaz akkor, ha a csomópont neighbor advertisement üzenetet kap, amiben a próbacíme az üzenet forrása. Az interfész csak akkor használhatja a címet, ha sikeresen megállapította, hogy az egyedi.

A címek élettartama

Minden interfészhez társított IPv6-címnek fix élettartama van. Ez alapértelmezetten végtelen, hacsak nincs másként konfigurálva. Kétfajta élettartam van, ami meghatározza egy cím állapotát: az előnyben részesített és az érvényes élettartam. Az élettartamokat lehet az útválasztókban konfigurálni, amelyek szolgáltatják ezeket az automatikus címkonfigurációhoz; vagy kézzel egy interfész címének beállításakor.

Egy cím interfészhez való hozzárendelésekor előnyben részesített státuszú lesz, amit az előnyben részesített élettartam lejártáig őriz meg. Ezután a státusza elavult (deprecated) lesz, és új kapcsolatokat nem szabad létesíteni a használatával. Ha az érvényességi időtartama is lejár, akkor érvénytelen (invalid) lesz, ekkor a cím lekerül az interfészről és újrafelhasználható valahol máshol.

Ideiglenes címek

A globálisan egyedi és statikus MAC-címek – amiket az állapotmentes automatikus címkonfiguráció használ az interfészazonosítók generálására – lehetővé teszik a felhasználói berendezések (és így a felhasználók) időbeni és IPv6 hálózati előtag változásbeni nyomonkövetését. Hogy csökkentse a felhasználói identitás permanens IPv6-címrészhez való kötöttségét, egy csomópont készíthet ideiglenes interfész-azonosítókat idő alapú véletlen bitsorozatok alapján relatív alacsony élettartamokkal (órák vagy napok), aminek lejárta után új címekre lesznek cserélve.

Az ideiglenes címek használhatóak forráscímként kapcsolatok felépítésére, míg a külső hosztok publikus címet használnak DNS-lekérdezés segítségével.

A Windows Vista, Windows 2008 Server és későbbi Microsoft operációs rendszerek alapértelmezetten ideiglenes címeket használnak az IPv6-ra konfigurált hálózati interfészeiknél.

Alapértelmezett cím kiválasztása

Az IPv6-képes hálózati interfészeknek általában több mint egy IPv6-címük van, például egy kapcsolati szintű és egy globális, és végleges vagy ideiglenes címek. Az IPv6 bevezeti a cím hatókörének és kiválasztásának fogalmát, több lehetőséget eredményezve a forrás- és célcímek megválasztásánál egy másik hoszttal történő kommunikáció során.

Az RFC 3484 adja meg az algoritmusokat egy konkrét célállomással való kommunikációhoz leginkább megfelelő cím kiválasztására, ideértve az IPv4-mapped címeket is a dual-stack implementációkban. A preferencia kiválasztási algoritmus egy felhasználó által testre szabható prefereciatáblán alapul, ami minden routolási előtagot egy elsőbbségi szinttel társít. Az alapértelmezett tábla a következő:

Alapértelmezett előtag-szabály tábla

Előtag	Precedencia	Címke
::1/128 ::/0 2002::/16 ::/96 ::ffff:0:0/96	50 40 30 20 10	0 1 2 3 4

Az alapértelmezett konfiguráció szerint mindig az IPv6 az elsődleges az IPv4 előtt, és a lehető legkisebb hatókörű célcímek. Így a kapcsolati szintű kommunikáció az előnyben részesített a globálisan routolt útvonalakhoz képest, akkor is, ha egyébként mindegyik megfelelő lenne. Az előtag-szabály tábla hasonló egy útválasztási táblához, amelyben a precedencia értéke megfelel az útvonal költségének (a magasabb preferenciát nagyobb érték jelöli). A jelölt forráscímeket az operációs rendszer szolgáltatja, a jelölt célcímeket pedig DNS-ből lehet lekérdezni. A címek illesztése az előtagokra a leghosszabban egyező nagy helyiértékű bitsorozat alapján történik.

Windows operációs rendszerben a következő paranccsal lehet megnézni az előtag-szabály táblát:

netsh interface ipv6 show prefixpolicies

Kapcsolati szintű címek és zónaindexek

Mivel az összes kapcsolati szintű címnek közös az előtagja egy hosztnál, a normál útválasztási folyamatok nem használhatóak a kimenő interfész kiválasztásához, ha egy kapcsolati szintű célhoz küldünk csomagot. Egy speciális azonosító, a zónaindex szükséges a plusz útválasztási információhoz; a kapcsolati szintű címek esetében a zónaindexek az interfészazonosítóknak felelnek meg.

Ha egy címet szövegszerűen írunk, a zónaindexet a végére egy százalék (%) jellel elválasztva kell írni. A zónaindexek valós szintaxisa operációs rendszer függő:

• a Microsoft Windows IPv6 stack numerikus zónaindexeket használ, például fe80::3%1. Az indexet az interfész azonosítószáma határozza meg;
• a legtöbb Unix-szerű rendszer (például BSD, Linux, Mac OS X) pedig az interfész nevét használja zónaindexként: fe80::3%eth0.

A zónaindex jelölés szintaxis-konfliktust okoz ha URI-ben használjuk, mert a „%” karakter a százalék-kódolást is jelzi.

IPv6-címzés a DNS-ben

A domainnevek rendszerében (DNS) a hosztneveket az AAAA erőforrásrekordok képezik le IPv6-címekre. A fordított lekérdezésekhez az IETF az ip6.arpa domént foglalta le, ahol a névtér hierarchikusan van felosztva az IPv6-címek egy-egy hexadecimális számjegye (nibble, 4 bit) alapján. Ezt az RFC 3596 definiálja. (Az alhálózaton belüli, DNS-szerver nélküli címfeloldást a NETBIOS „utódja”, a Link Local Multicast Name Resolution vagy LLMNR protokoll végzi.)

Mint az IPv4-nél, minden hosztot két rekord reprezentál a DNS-ben, egy címrekord és egy fordítottan leképzett mutatórekord. Például az agamemnon nevű hoszt egyedi helyi címe a pelda.hu zónában fdda:5cc1:23:4::1f. Az AAAA címrekordja:

agamemnon.pelda.hu. IN AAAA fdda:5cc1:23:4::1f

és az IPv6 mutatórekordja:

f.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.0.0.0.3.2.0.0.1.c.c.5.a.d.d.f.ip6.arpa. IN PTR agamemnon.pelda.hu.

Ezt a mutatórekordot definiálhatjuk számos zónában, függően a jogosultság-átruházási lánctól a d.f.ip6.arpa-ban.

A DNS protokoll független a szállítási rétegbeli protokolltól. A kérések és válaszok közlekedhetnek IPv6- vagy IPv4-alapon attól függetlenül, hogy maga a DNS-kérés v4- vagy v6-címet tartalmaz.

AAAA rekord mezők

NAME	doménnév
TYPE	AAAA (28)
CLASS	internet (1)
TTL	élettartam másodpercekben
RDLENGTH	az RDATA mező hossza
RDATA	az IPv6-cím szöveges alakja

Migrációs kihívások

2009-ben még sok otthoni NAT eszköz és router DNS-feloldója hibásan kezelte az AAAA rekordokat. Néhány közülük egyszerűen eldobja az ilyen rekordokhoz tartozó kéréseket, ahelyett hogy helyesen visszaadná a megfelelő negatív DNS-választ. Mivel a kérés eldobásra kerül, az azt küldő hosztnak ki kell várnia a timeoutját. Ez gyakran érezhetően lassítja az IPv6-hosztokhoz való csatlakozást.

Történeti megjegyzések

• Az fec0::/10 site-local előtag a cím érvényességét egy szervezet site-hálózatára korlátozta. Az eredeti címzési architektúra része volt 1995-ben, de a használata érvénytelenítve lett 2004 szeptemberében, mert a site kifejezés meghatározása nem volt egyértelmű, ami megtévesztő útválasztási szabályokat eredményezett. Az új hálózatoknak nem szabad támogatniuk ezt a speciális típusú címet. 2005 októberében egy új specifikáció lecserélte ezeket a címeket, és bevezette az egyedi helyi címek fogalmát.
• A 0200::/7 címtartomány egy OSI NSAP-leképzett tartománynak lett definiálva 1996-ban, de 2004-ben érvénytelenítve lett.
• A ::/96 96 bitnyi nullát tartalmazó előtagot először 1995-ben említik, de 1998-ban írják le részletesen. Eredeti neve IPv4-kompatibilis címek. Ezt a címosztályt használták az IPv4-címek ábrázolására egy IPv6-átmeneti technológiában. Egy ilyen IPv6-cím első (magas helyiértékű) 96 bitje nulla, míg az utolsó 32 bitje az általa reprezentált IPv4-cím. 2006 februárjában az IETF érvénytelenítette az IPv4 kompatibilis címek használatát. Az egyetlen további haszna ennek a formátumnak az, hogy IPv4-címeket lehet vele ábrázolni fix méretű tagokkal rendelkező táblázatban vagy adatbázisban, ami alapvetően IPv6-címeket tárol.
• Az IPv6-címeket eredetileg az ip6 zónában regisztrálták az .int legfelső szintű domén alatt a DNS-ben a fordított lekérdezésekhez. 2000-ben az Internet Architecture Board (IAB) meggondolta azon szándékát, hogy a .arpa címet átnevezze .int-re, és úgy döntött, hogy a .arpa legfelső szintű domén megtartja eredeti funkcióját. Amely címek már regisztrálva voltak az ip6.int alatt, költözniük kellett az ip6.arpa cím alá. Az IAB ezt 2001-ben tette hivatalossá. Az ip6.int zóna hivatalosan 2006. június 6-án szűnt meg.
• A 3ffe::/16-os blokkot tesztcélokra allokálták a 6bone hálózat számára, 1998 decemberében. Ezt megelőzően az 5F00::/8 tartomány szolgált erre a célra. Mindkét blokkot visszaadták a címkészletbe 2006 júniusában.

További információk

• IPv6 multicast címek (angolul)
• Beijnum, van, Iljitsch. Running IPv6 [archivált változat] (2005). ISBN 1-59059-527-0. Hozzáférés ideje: 2011. március 16. [archiválás ideje: 2012. október 18.] 
• Elz, Robert: A Compact Representation of IPv6 Addresses. IETF, 1996. április 1. „Represent any IPv6 address in 20 octets.” – ez az „áprilisi tréfa” RFC az IPv6 címek egy alternatív reprezentációját mutatja be, 85-ös számrendszer használatával