Wikipédia

IPv6-cím

számítógép hálózati fogalom; hexadecimális szá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 szerkesztés

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

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

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

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

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

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

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

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

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) szerkesztés

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

Általános felosztás szerkesztés

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·1038) 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

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 0x00 – 0x7d értékek is a fenntartottak közé tartoznak.

Speciális címek szerkesztés

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

Nem specifikált cím szerkesztés

  • ::/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

  • ::/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

  • ::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

  • 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

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

  • ::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.[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

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::/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,[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

  • 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

 Bővebben: #Történeti megjegyzések

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

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

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:[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

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

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 újrafelhasználható valahol máshol.

Ideiglenes címek szerkesztés

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

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 prefixpolicies

Kapcsolati szintű címek és zónaindexek szerkesztés

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

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

Migrációs kihívások szerkesztés

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

  • 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]

Jegyzetek szerkesztés

  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[halott link]
  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. [2011. június 7-i dátummal az eredetiből archiválva] (Hozzáférés ideje: 2011. március 16.) 
  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)

További információk szerkesztés

A lap eredeti címe: „https://hu.wikipedia.org/w/index.php?title=IPv6-cím&oldid=25897177”