| IPv6 | |
|---|---|
| Név | Internet protokoll 6-os verzió |
| Szint ( az OSI modell szerint ) | hálózat |
| Család | TCP/IP |
| Létrehozva: | 1996 |
| Port/ID | Nem |
| A protokoll célja | Megszólítás |
| Leírás | RFC 8200 |
| Főbb megvalósítások (kliensek) | a TCP/IP verem megvalósítása Microsoft Windows , Linux és BSD rendszerben |
| Alapvető megvalósítások ( szerverek ) | a TCP/IP verem implementációi Windows , Linux és BSD rendszerekben |
| Médiafájlok a Wikimedia Commons oldalon | |
Az IPv6 ( angolul Internet Protocol version 6 ) az Internet Protokoll ( IP ) új verziója, amelyet arra terveztek, hogy megoldja azokat a problémákat, amelyekkel az előző verzió ( IPv4 ) az internetes használata során számos alapvető változás miatt szembesült . A protokollt az IETF fejlesztette ki . Az IPv6-cím 128 bites , ellentétben a 32 bites IPv4-címmel.
2012 végén az IPv6 részesedése a hálózati forgalomból körülbelül 5% volt [1] . 2013 végére 3%-os növekedést vártak [2] . A Google 2020. januári statisztikái szerint az IPv6 részesedése a hálózati forgalomban körülbelül 30% volt. [3] Oroszországban a távközlési szolgáltatók kereskedelmi felhasználása csekély (a forgalom legfeljebb 4,5%-a). Számos orosz domainregisztrátor és tárhelyszolgáltató DNS -kiszolgálója IPv6-ot használ.
Miután az IPv4 címterülete elfogy, két protokollverem – az IPv6 és az IPv4 – párhuzamosan kerül felhasználásra ( eng. dual stack ), az IPv6 forgalom aránya fokozatosan nő az IPv4-hez képest. Ez a helyzet nagyszámú eszköz jelenléte miatt válik lehetővé, beleértve az örökölt eszközöket is, amelyek nem támogatják az IPv6-ot, és speciális átalakítást igényelnek a csak IPv6-ot használó eszközökkel való együttműködéshez.
Az 1980-as évek végén nyilvánvalóvá vált, hogy ki kell dolgozni az internet címterének megőrzésének módjait. Az 1990-es évek elején az osztály nélküli címzés bevezetése ellenére világossá vált, hogy ez nem elég a címek kimerülésének megakadályozásához, és további változtatásokra van szükség az internet infrastruktúrájában. 1992 elejére több javaslat is megjelent, majd 1992 végére az IETF pályázatot hirdetett munkacsoportok számára a következő generációs Internet protokoll ( eng. IP Next Generation – IPng) létrehozására. 1994. július 25- én az IETF több IPng munkacsoport megalakításával jóváhagyta az IPng modellt. 1996 - ra egy sor RFC -t adtak ki , amelyek meghatározták az Internet Protocol 6-os verzióját, kezdve az RFC 1883 -mal .
Az IETF a 6-os verziót rendelte hozzá az új protokollhoz, mivel az 5-ös verziót korábban egy kísérleti protokollhoz rendelték a kép- és hangátvitelhez.
Az IPv4 - címek elfogyásához szükséges idő becslései a 2000 - es években teljesen eltérőek voltak . Tehát 2003 -ban az APNIC igazgatója , Paul Wilson ( Eg. Paul Wilson ) azt mondta, hogy az internet akkori elterjedtségi üteme alapján egy-két évtizedre elegendő szabad címterület lesz. 2005 szeptemberében a Cisco Systems úgy becsülte, hogy a rendelkezésre álló címek készlete 4-5 évig tart majd.
2011. február 3- án az IANA kiosztotta az utolsó öt /8 IPv4-blokkot a regionális internetes regisztrátoroknak . Ezen a ponton azt várták, hogy a regionális internetes regisztrátoroknál ( RIR ) a teljes ingyenes címblokkok kínálata hat hónap ( APNIC ) és öt év ( AfriNIC ) közötti időszakon belül elfogy [4] .
2015 szeptemberétől az AfriNIC kivételével minden regionális regisztrátor bejelentette, hogy kifogyott az összes ingyenes IPv4-címblokkból, és korlátozzák az új címtartományok kiadását; Az ARIN bejelentette az ingyenes IPv4-címek teljes kimerülését, a többi regisztrátor számára pedig ezt a pillanatot 2017 -től jósolják . Az IPv4-címek kiosztása Európában, Ázsiában és Latin-Amerikában ( APNIC , RIPE NCC és LACNIC regisztrátorok ) a /22-es blokkban (egyenként 1024 cím) folytatódik [5] [6]
2011. június 8- án volt az IPv6 Nemzetközi Napja, amely a globális internetes közösség felkészültségét próbálta tesztelni az IPv4-ről IPv6-ra való átállásra, amelyen a résztvevő vállalatok egy napra IPv6-rekordokat adtak webhelyeikhez. A tesztelés sikeres volt, a felhalmozott adatokat elemezzük és figyelembe veszik a protokoll későbbi megvalósítása során, valamint az ajánlások elkészítésekor.
Az IPv6-ra történő fordítást 2008 óta kezdték el végezni a Google -on belül . Az IPv6 tesztelése sikeresnek tekinthető [7] . 2012. június 6- án került sor az IPv6 [8] világméretű bevezetésére . Az internetszolgáltatók felhasználóik legalább 1%-a számára engedélyezni fogják az IPv6-ot (az AT &T , a Comcast , a Free Telecom Internode KDDI , a Time Warner Cable , az már előfizetett ) A hálózati berendezések gyártói engedélyezik az IPv6 alapértelmezett beállításait az útválasztókban (Cisco, D-Link ). A webcégek fő oldalaikon (Google, Facebook , Microsoft Bing , Yahoo ) engedélyezni fogják az IPv6-ot, és néhányan a vállalati hálózatokat is áttelepítik az IPv6-ra. Az LTE mobilhálózati szabvány specifikációja meghatározza az IPv6 protokoll kötelező támogatását.
Néha azt állítják, hogy az új protokoll akár 5·10 28 címet is biztosíthat a Föld minden lakója számára. Ekkora címteret a hierarchikus címek miatt vezettek be (ez leegyszerűsíti az útválasztást). A megnövekedett címtér azonban szükségtelenné teszi a NAT -ot. Az IPv6 klasszikus használata (előfizetőnként a /64-es hálózaton keresztül; csak unicast címzést használnak) a Föld lakosánként több mint 300 millió IP-cím használatára lesz lehetőség.
Az IPv6-ból eltávolították azokat a funkciókat, amelyek megnehezítik az útválasztók munkáját:
Annak ellenére, hogy az IPv6-cím nagyobb mérete volt a protokoll előző verziójához képest (4 helyett 16 bájt), a csomagfejléc csak kétszer olyan hosszú volt: 20-tól 40 bájtig.
IPv6 fejlesztések az IPv4-hez képest:
A hálózati interfész inicializálása során egy helyi IPv6 címet rendelnek hozzá, amely a fe80::/10 előtagból és a cím alsó részében elhelyezett interfész azonosítóból áll. Az interfész azonosítója gyakran a 64 bites EUI-64 Extended Unique Identifier , amelyet gyakran MAC-címhez társítanak . A helyi cím csak a kapcsolati réteg hálózati szegmensén belül érvényes, és az ICMPv6 információs csomagok cseréjére szolgál.
Más címek konfigurálásához a gazdagép hálózati konfigurációs információkat kérhet az útválasztóktól úgy, hogy ICMPv6 „Router Solicitation” üzenetet küld az útválasztók csoportos küldési címére. Az ezt az üzenetet kapó útválasztók egy ICMPv6 "Router Advertisement" üzenettel válaszolnak, amely információkat tartalmazhat a hálózati előtagról, az átjáró címéről , a rekurzív DNS - kiszolgáló címeiről [9] , az MTU -ról és sok más paraméterről. A hálózati előtag és az interfészazonosító kombinálásával a csomópont új címet kap. A személyes adatok védelme érdekében az interfész azonosítója helyettesíthető pszeudo-véletlen számmal.
További adminisztratív vezérléshez a DHCPv6 használható , amely lehetővé teszi az útválasztó rendszergazdája számára, hogy egy adott címet rendeljen a gazdagéphez.
A szolgáltatók számára a kliens előtag delegálási funkciója használható, amely lehetővé teszi az ügyfél számára, hogy a beállítások módosítása nélkül egyszerűen váltson szolgáltatóról szolgáltatóra.
A „Stream Label” mező bevezetése az IPv6 protokollban lehetővé teszi a homogén csomagfolyamok útválasztási eljárásának jelentős egyszerűsítését. A folyam a feladótól egy adott célállomásra küldött csomagok sorozata. Feltételezzük, hogy egy adott adatfolyam minden csomagját bizonyos feldolgozásnak kell alávetni. A feldolgozás jellegét további fejlécek határozzák meg.
Több áramlás is megengedett a küldő és a fogadó között. Az adatfolyam címkéjét a küldő csomópont rendeli hozzá egy pszeudo-véletlen 20 bites szám generálásával. Ugyanazon folyam minden csomagjának ugyanazokkal a fejlécekkel kell rendelkeznie, amelyeket az útválasztó dolgoz fel .
Az első folyamcímkével ellátott csomag kézhezvételekor a router további fejléceket elemz, végrehajtja az ezek által előírt funkciókat, és eltárolja a feldolgozási eredményeket (következő ugrás címe, ugrásfejléc opciók, címek áthelyezése az útválasztási fejlécben stb.) egy helyi gyorsítótárban . Az ilyen bejegyzés kulcsa a forráscím és az adatfolyamcímke kombinációja. A következő csomagokat a forráscím és a folyamatcímke azonos kombinációjával a rendszer gyorsítótár-információk felhasználásával dolgozza fel, az összes fejlécmező részletes elemzése nélkül.
A gyorsítótár-bejegyzés élettartama nem haladja meg a 6 másodpercet, még akkor sem, ha továbbra is érkeznek csomagok ebből az adatfolyamból. A gyorsítótár-bejegyzés alaphelyzetbe állításakor és a következő adatfolyam-csomag vételekor a csomag normál módban kerül feldolgozásra, és új gyorsítótár-bejegyzés jön létre hozzá. A megadott adatfolyam-élettartamot a kiinduló gazdagép kifejezetten meghatározhatja a vezérlőprotokoll vagy az ugrásfejléc-beállítások segítségével, és hosszabb lehet 6 másodpercnél.
Az IPv6 protokoll biztonsága az IPsec protokoll segítségével történik, amelynek támogatása a protokoll ezen verziójához kötelező.
A csomagokat a forgalomirányítók a Traffic Class mező első hat bitje alapján rangsorolják . Az első három bit határozza meg a forgalmi osztályt, a többi bit pedig a törlési prioritást. Minél magasabb a prioritási érték, annál magasabb a csomag prioritása .
Az IPv6-fejlesztők a következő forgalmi osztálykódok használatát javasolják bizonyos alkalmazáskategóriákhoz:
| Forgalmi osztály | Célja |
|---|---|
| 0 | Jellemzetlen forgalom |
| egy | Forgalom feltöltése (hálózati hírek) |
| 2 | Nem alapvető információforgalom (e-mail) |
| 3 | lefoglal |
| négy | Alapvető forgalom ( FTP , HTTP , NFS ) |
| 5 | lefoglal |
| 6 | Interaktív forgalom ( Telnet , X-terminál , SSH ) |
| 7 | Menedzsment forgalom ( Routing information , SNMP ) |
Az SSL -től és a TLS -től eltérően az IPsec -protokoll lehetővé teszi bármilyen adat (beleértve az UDP -t is) titkosítását anélkül, hogy az alkalmazásszoftvertől bármiféle támogatásra lenne szükség .
Különféle IPv6-címek léteznek: unicast ( Unicast ), multicast ( Anycast ) és multicast ( Multicast ).
Az Unicast címeket mindenki jól ismeri. Az ilyen címre küldött csomag pontosan az adott címnek megfelelő interfészt éri el.
Az Anycast-címek szintaktikailag nem különböztethetők meg az Unicast-címektől, de interfészek egy csoportját szólítják meg. Az ilyen címre szánt csomag a legközelebbi (az útválasztó metrikája szerint) interfészre kerül. Anycast címeket csak útválasztók használhatnak.
A multicast címek interfészek csoportját azonosítják. Az ilyen címre küldött csomagok elérik a multicast csoporthoz tartozó összes interfészt.
Az IPv4 szórási címek (általában xxx.xxx.xxx.255) IPv6 csoportos küldési címként vannak kifejezve. A szélsőséges IPv6 alhálózati címek (például xxxx: xxxx: xxxx: xxxx:0:0:0:0 és xxxx: xxxx: xxxx: xxxx: ffff: ffff: ffff: ffff a /64 alhálózathoz) teljes címek és felváltva használható a többivel.
A címben szereplő számjegycsoportokat kettőspont választja el (például fe80:0:0:0:200:f8ff: fe21:67cf). A csoportokban a jelentéktelen kezdő nullák elhagyhatók. Nagyszámú nullcsoport átugorható kettős kettőspont használatával (fe80::200:f8ff: fe21:67cf). Egy ilyen bérletnek kell lennie a címben.
Megfelel a nyilvános IPv4-címeknek. Bármilyen szabad tartományban lehetnek. Jelenleg a RIR -ek 2000::/3 címblokkot osztanak ki (2000::-től 3FFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF-ig) [10] .
Megfelel az APIPA protokoll használatával automatikusan konfigurált IPv4-címeknek . FE80-tól kezdve:.
Használt:
Az RFC 4193 a belső IP-címeknek felel meg, amelyek az IPv4-ben 10.0.0.0/8, 172.16.0.0/12 és 192.168.0.0/16. Kezdje az FCxx: és az FDxx: számjegyekkel.
A multicast címeknek két típusa van:
A csomagok a csomag célállomásra való eljuttatásához szükséges vezérlőinformációkat és a küldendő hasznos terhet tartalmazzák. A vezérlő információ a fő rögzített fejlécben és az opcionális kiegészítő fejlécek egyikében található. A hasznos adat általában egy datagram vagy magasabb szállítási réteg protokolltöredéke , de lehet hálózati rétegbeli adat is (pl . ICMPv6 , OSPF ).
Az IPv6 - csomagok továbbítása általában kapcsolati rétegbeli protokollok használatával történik , mint például az Ethernet , amely minden csomagot egy keretbe foglal . Az IPv6-csomagok azonban továbbíthatók magasabb szintű alagútkezelési protokollal, mint például a 6to4 vagy a Teredo .
Az IPv6-címek nyolc négyjegyű hexadecimális számként (azaz négy karakterből álló csoportokként) jelennek meg, kettősponttal elválasztva. Példa a címre:
2001:0db8:11a3:09d7:1f34:8a2e:07a0:765dHa egy sorban két vagy több csoport egyenlő 0000-nel, akkor ezek elhagyhatók, és kettős kettősponttal (::) helyettesíthetők. A csoportokban a jelentéktelen kezdő nullák elhagyhatók. Például a 2001:0db8:0000:0000:0000:0000:ae21:ad12 lerövidíthető 2001:db8::ae21:ad12-re, vagy a 0000:0000:0000:0000:0000:0000:0000:0000:001 rövidíthető: to ::ae21:ad12. A két különálló nullcsoport a kétértelműség miatt nem redukálható.
Van egy speciális jelölés is a beágyazott és leképezett IPv4-ről IPv6-ra írásához. Ebben az utolsó 2 karaktercsoport egy IPv4-címre van helyettesítve a formátumában. Példa:
::ffff:192.0.2.1Ha IPv6-címet használ egy URL -ben , a címet szögletes zárójelek közé kell tenni:
http://[2001:0db8:11a3:09d7:1f34:8a2e:07a0:765d]/Ha meg kell adni a portot, akkor azt a zárójelek után kell írni:
http://[2001:0db8:11a3:09d7:1f34:8a2e:07a0:765d]:8080/| IPv6-cím | Előtag hossza (bit) | Leírás | Megjegyzések |
|---|---|---|---|
| :: | 128 | — | lásd a 0.0.0.0-t IPv4 -ben |
| ::egy | 128 | hurokcím _ | lásd: 127.0.0.0/8 IPv4 -ben |
| ::xx.xx.xx.xx | 96 | beágyazott IPv4 | Az alsó 32 bit az IPv4 -cím . IPv4 - kompatibilis IPv6-címnek is nevezik . Elavult és már nem használt. |
| ::ffff:xx.xx.xx.xx | 96 | IPv4-cím leképezve IPv6-ra | Az alsó 32 bit a nem IPv6-os gazdagépek IPv4 -címe. |
| 64:ff9b:: | 96 | NAT64 | Az IPv6-alhálózatról a nyilvános IPv4-hálózatra a NAT64 fordítómechanizmuson keresztüli hozzáférésre fenntartva [13] [14] |
| 2001:: | 32 | Teredo | Teredo alagutak számára fenntartva az RFC 4380 -ban |
| 2001:db8:: | 32 | Dokumentáció | Az RFC 3849 -ben található dokumentációs példák számára fenntartva |
| 2002:: | 16 | 6-4 | 6-4 alagutak számára fenntartva az RFC 3056 -ban |
| fe80::-febf:: | tíz | link-local [15] [16] | Analóg 169.254.0.0/16 IPv4-ben |
| fec0::-feff:: | tíz | hely-helyi
|
Elavultként megjelölve az RFC 3879 -ben (Hasonló a belső hálózatokhoz 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16) |
| fc00:: | 7 | Egyedülálló helyi Unicast | Helyi helyi RFC 4193 lecserélve |
| ff00:: | nyolc | Multicast | RFC 3513 |
| Fő | |
|---|---|
| Végrehajtás |
|
| Migráció IPv4-ről IPv6-ra |
|
| Kapcsolódó protokollok |
|
| Alapvető TCP / IP protokollok az OSI modell rétegei szerint | |
|---|---|
| Fizikai | |
| csatornázott | |
| hálózat | |
| Szállítás | |
| ülés | |
| Reprezentáció | |
| Alkalmazott | |
| Egyéb alkalmazva | |
| A TCP és UDP portok listája | |