IPv6-cím

A Wikipédiából, a szabad enciklopédiából

Az internetprotokoll 6-os verziójú cím (IPv6-cím) egy bináris 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[szerkesztés | forrásszöveg szerkesztése]

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

  • 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[szerkesztés | forrásszöveg szerkesztése]

Az IPv6-címek 128 bitből állnak.[1] 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[szerkesztés | forrásszöveg szerkesztése]

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[szerkesztés | forrásszöveg szerkesztése]

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[1], 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[2][3]
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.[4]

Ábrázolás[szerkesztés | forrásszöveg szerkesztése]

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

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 (::).[5] 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[szerkesztés | forrásszöveg szerkesztése]

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[szerkesztés | forrásszöveg szerkesztése]

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 2128 – 48 = 280 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[szerkesztés | forrásszöveg szerkesztése]

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.[6] 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[szerkesztés | forrásszöveg szerkesztése]

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:73482001-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)[szerkesztés | forrásszöveg szerkesztése]

Minden IPv6-címnek – kivéve a nem specifikált címet (::) – van egy hatóköre[7], 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[1] 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[szerkesztés | forrásszöveg szerkesztése]

Általános felosztás[szerkesztés | forrásszöveg szerkesztése]

Az IPv6-címek kiosztását az IANA[8] 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.[9]

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.[10]

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[11][12][13]. Végül a végfelhasználók általában /48/56 méretű blokkokat kapnak.[14] 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.[15]

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 280 címet tartalmaz, így 248-szor (avagy 7,2 × 1016-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 2128 (vagy 3,4 × 10 38) 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.[16] 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 232, vagy másként 4,3 × 109 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[szerkesztés | forrásszöveg szerkesztése]

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.[1] 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.[17] 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 0x000x7d értékek is a fenntartottak közé tartoznak.

Speciális címek[szerkesztés | forrásszöveg szerkesztése]

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

Nem specifikált cím[szerkesztés | forrásszöveg szerkesztése]

  • ::/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ó[szerkesztés | forrásszöveg szerkesztése]

  • ::/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[szerkesztés | forrásszöveg szerkesztése]

  • ::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[szerkesztés | forrásszöveg szerkesztése]

  • 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).[19] 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[szerkesztés | forrásszöveg szerkesztése]

Az ff00::0/12 multicast címek fent vannak tartva[1], é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[szerkesztés | forrásszöveg szerkesztése]

  • ::ffff:0:0/96IPv4-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/96IPv4-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.[20]
  • 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[21][szerkesztés | forrásszöveg szerkesztése]

A IANA allokált egy úgynevezett „Sub-TLA ID” címtartományt[22], ami 64 hálózati előtagból áll a 2001:0000::/292001: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[23], 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)[24]: nem routolható IPv6 címek, amelyeket kriptografikus hasítófüggvény-azonosítókként használnak.

Dokumentáció[szerkesztés | forrásszöveg szerkesztése]

  • 2001:db8::/32 — ezt az előtagot a dokumentációkban használjuk.[25] 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).[26]

Érvénytelenített és elavult címek[szerkesztés | forrásszöveg szerkesztése]

Állapotmentes automatikus címkonfiguráció (SLAAC)[szerkesztés | forrásszöveg szerkesztése]

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[27], 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.[28]

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[szerkesztés | forrásszöveg szerkesztése]

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özepére 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[1]: 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[szerkesztés | forrásszöveg szerkeszté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[szerkesztés | forrásszöveg szerkesztése]

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.[29] 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 újra felhasználható valahol máshol.

Ideiglenes címek[szerkesztés | forrásszöveg szerkesztése]

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.[30] 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[31] 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[szerkesztés | forrásszöveg szerkesztése]

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.[32] 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ő:[32]

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 prefixpolicy

Kapcsolati szintű címek és zónaindexek[szerkesztés | forrásszöveg szerkesztése]

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[7] 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.[33]

IPv6-címzés a DNS-ben[szerkesztés | forrásszöveg szerkesztése]

A domainnevek rendszerében (DNS) egy 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[1]

Migrációs kihívások[szerkesztés | forrásszöveg szerkesztése]

2009-ben még sok otthoni NAT eszköz és router DNS-feloldója hibásan kezelte az AAAA rekordokat.[34] 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[szerkesztés | forrásszöveg szerkesztése]

  • 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[35], de a használata érvénytelenítve lett 2004 szeptemberében[36], 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ó[37] 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[38][39], de 2004-ben érvénytelenítve lett.[40]
  • A ::/96 96 bitnyi nullát tartalmazó előtagot először 1995-ben említik[35], de 1998-ban írják le részletesen[41]. 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.[1] 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á.[42] 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.[41] 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.[43]

Források[szerkesztés | forrásszöveg szerkesztése]

  1. ^ a b c d e f g h i RFC 4291, IP Version 6 Addressing Architecture, R. Hinden, S. Deering (February 2006)
  2. RFC 3306, Unicast-Prefix-based IPv6 Multicast Addresses, B. Haberman, D. Thaler (August 2002)
  3. RFC 3956, Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address P. Savola, B. Haberman (November 2004)
  4. RFC 4489, A Method for Generating Link-Scoped IPv6 Multicast Addresses, J-S. Park, M-K. Shin; H-J. Kim (April 2006)
  5. ^ a b RFC 5952, "A Recommendation for IPv6 Address Text Representation", S. Kawamura, M. Kawashima, (August 2010)
  6. RFC 3986, Uniform Resource Identifier (URI): Generic Syntax, T. Berners-Lee, R. Fielding, L. Masinter (January 2005)
  7. ^ a b RFC 4007, IPv6 Scoped Address Architecture, S.Deering, B. Haberman, T. Jinmei, E. Nordmark, B. Zill (March 2005)
  8. RFC 1881, IPv6 Address Allocation Management, Internet Architecture Board (December 1995)
  9. IPv6 address space at IANA
  10. IPv6 unicast address assignments, IANA
  11. DE-TELEKOM-20050113
  12. ARIN Number Resource Policy Manual: Initial allocation to ISPs
  13. RIPE NCC IPv6 Address Allocation and Assignment Policy: Minimum allocation
  14. RFC 3177, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", IAB, IESG, (September 2001).
  15. Például: SIXXS Ghost Route Hunter
  16. IPv6 Addressing Plans. ARIN IPv6 Wiki. (Hozzáférés: 2010. augusztus 18.) „All customers get one /48 unless they can show that they need more than 65k subnets. [...] If you have lots of consumer customers you may want to assign /56s to private residence sites.”
  17. RFC 2526,Reserved IPv6 Subnet Anycast Addresses, D. Johnson, S. Deering (March 1999)
  18. RFC 5156, Special-Use IPv6 Addresses, M. Blanchett (April 2008)
  19. RFC 1918, Address Allocation for Private Internets, Y. Rekhter, B. Moskowitz, D. Karrenberg, G.J. De Groot, E. Lear (February 1996)
  20. RFC 6052, "IPv6 Addressing of IPv4/IPv6 Translators", C. Bao, C. Huitema, M. Bagnulo, M. Boucadair, X. Li, (October 2010)
  21. RFC 4773, Administration of the IANA Special Purpose IPv6 Address Block, G. Huston (December 2006)
  22. RFC 2928, Initial IPv6 Sub-TLA ID Assignments, R. Hinden, S. Deering, R. Fink, T. Hain (September 2000) The Internet Society
  23. RFC 5180, IPv6 Benchmarking Methodology for Network Interconnect Devices, C. Popoviciu, A. Hamza, G. Van de Velde, D. Dugatkin (May 2008)
  24. RFC 4843 (experimental), An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID), P. Nikander, J. Laganier, F. Dupont (April 2007)
  25. RFC 3849, IPv6 Address Prefix Reserved for Documentation, G. Huston, A. Lord, P. Smith (July 2004)
  26. RFC 5737, IPv4 Address Blocks Reserved for Documentation, J. Arkko, M. Cotton, L. Vegoda (January 2010), ISSN: 2070-1721
  27. RFC 4862, IPv6 Stateless Address Autoconfiguration, S. Thomson, T. Narten, T. Jinmei (September 2007)
  28. RFC 4861, Neighbor Discovery for IP version 6 (IPv6), T. Narten, E. Nordmark, W. Simpson, H. Holiman (September 2007)
  29. Iljitsch van Beijnum. „IPv6 Internals”, 16–29. oldal 
  30. The privacy implications of stateless IPv6 addressing
  31. RFC 4941, Privacy Extensions for Stateless Address Autoconfiguration in IPv6, T. Narten, R. Draves, S. Krishnan (September 2007)
  32. ^ a b RFC 3484, Default Address Selection for Internet Protocol version 6 (IPv6), R. Draves, The Internet Society (February 2003)
  33. Formats for IPv6 Scope Zone Identifiers in Literal Address Formats
  34. RFC 4074 Common Misbehavior Against DNS Queries for IPv6 Addresses, Y. Morishita, T. Jinmei. May 2005.
  35. ^ a b RFC 1884, IP Version 6 Addressing Architecture, R. Hinden, S. Deering (dec 1995)
  36. RFC 3879, Deprecating Site Local Addresses, C. Huitema, B. Carpenter (sep 2004)
  37. RFC 4193, Unique Local IPv6 Unicast Addresses, R. Hinden, B. Haberman (oct 2005)
  38. RFC 4147, Proposed Changes to the Format of the IANA IPv6 Registry, G. Houston (aug 2005)
  39. RFC 1888, OSI NSAPs and IPv6, J. Bound, B. Carpenter, D. Harrington, J. Houldsworth, A. Lloyd (aug 1996)
  40. RFC 4048, RFC 1888 Is Obsolete, B. Carpenter (apr 2005)
  41. ^ a b RFC 2471, IPv6 Testing Address Allocation, R. Hinden, R. Fink, J. Postel (dec 1998)
  42. RFC 3152, Delegation of IP6.ARPA, R. Bush (aug 2001)
  43. RFC 3701, 6bone (IPv6 Testing Address Allocation) Phaseout, R. Fink, R. Hinden (mar 2004)

Külső hivatkozások[szerkesztés | forrásszöveg szerkesztése]