IPv6 ( Internet Protocol version 6 ) egy hálózati protokoll nélkül kapcsolatot a 3 réteg a OSI (Nyílt rendszerek összekapcsolása).
Az IPv6 az IETF- ben az 1990-es években az IPv4 sikere érdekében végzett munka csúcspontja, és specifikációit az RFC 2460- ban véglegesítették1998 december. Az IPv6 szabványt az RFC 8200 szabványban in2017. július.
A 32 bites helyett 128 bites címeknek köszönhetően az IPv6-nak sokkal nagyobb a címtere , mint az IPv4-nek (több mint 340 sextillió , vagy 340,10 36 , vagy csaknem 7,9 × 10 28- szor több, mint az előző). Ez a jelentős számú cím nagyobb rugalmasságot biztosít a címek kiosztásában és az útvonalak jobb összesítését az internetes útválasztási táblázatban . A címfordítás , amelyet az IPv4-címek hiánya tett népszerűvé, már nem szükséges.
Az IPv6 automatikus címkiosztási mechanizmusokkal is rendelkezik, és megkönnyíti az újraszámozást. Az IPv4-ben változó alhálózat méretét 64 biten rögzítették az IPv6-ban. Az olyan biztonsági mechanizmusok, mint az IPsec , az alapvető protokoll-specifikációk részét képezik. Az IPv6 csomagfejléc egyszerűsödött, és a helyi címtípusok megkönnyítik a magánhálózatok összekapcsolását.
Az IPv6 interneten keresztüli telepítése az IPv4 és az IPv6 címek inkompatibilitása miatt bonyolult. Az automatikus címfordítók jelentős gyakorlati problémákkal szembesülnek ( RFC 4966). Egy olyan átmeneti szakaszban, amikor az IPv6 és az IPv4 együtt létezik, a gazdagépeknek kettős veremük van, vagyis mind IPv6, mind IPv4 címmel rendelkeznek, és az alagutak olyan útválasztók csoportjain haladnak át , amelyek még nem támogatják az IPv6-ot.
2011-ben csak néhány vállalat vállalta az IPv6 technológia bevezetését a belső hálózatán, különösen a Google .
2016 elején az IPv6 telepítése még mindig korlátozott volt, az IPv6-ot használó internetezők arányát 10% -ra becsülték, annak ellenére, hogy sürgősen felhívták az internetszolgáltatókhoz intézett migrációt . Internet- és tartalomszolgáltatók a regionális internetes nyilvántartásokból és az ICANN-ból , mivel a rendelkezésre álló nyilvános IPv4-címek kimerülnek .
Az IPv4 protokoll valamivel több mint négymilliárd különböző cím használatát teszi lehetővé számítógépek és egyéb eszközök csatlakoztatásához a hálózaton. Amikor az 1970-es években elindult az internet, gyakorlatilag elképzelhetetlen volt, hogy egyetlen hálózatban valaha is legyen elég gép a rendelkezésre álló címek elfogyásához.
Az elméletileg rendelkezésre álló négymilliárd IP-cím némelyike nem használható gépek számozására, vagy azért, mert meghatározott felhasználásra szánják őket (például multicast vagy privát hálózatokra ), vagy azért, mert nem hatékonyan osztották fel őket.
Az 1990-es évekig a címeket osztályok formájában osztották szét , 16 millió (A osztály ), 65 536 ( B osztály ) vagy 256 ( C osztály ) blokkot osztottak ki a kérelmezőknek, néha jóval meghaladva a valós igényeket. Például az első nagy, internethez csatlakozó szervezeteknek 16 millió címet osztottak ki.
A korai 1990-es évek, szemben a kimerültség a címtartomány, különösen a B osztályú hálózatok ( RFC 1338), a regionális internetes nyilvántartások megjelent és a szétválás a címeket osztályokba eltörölték javára a legrugalmasabb. CIDR . A címek kiosztása hatékonyabbá válik, és figyelembe veszi a valós igényeket, miközben lehetővé teszi az Internet összes útvonala megfelelő működéséhez szükséges összesítés bizonyos szintjét, amely antagonista.
Az új alkalmazások, mobil eszközök és tartósan csatlakoztatott eszközök iránti növekvő kereslet a magáncímek , a hálózati címfordítás (NAT) és az adatok dinamikus hozzárendelésének fokozódó használatához vezet .
Ezen erőfeszítések ellenére a nyilvános IPv4-címek kimerülése elkerülhetetlen. Ez a fő oka annak, hogy az 1990-es években az Internet Engineering Task Force (IETF) keretében új internetes protokollt fejlesztettek ki .
A 2011. február 3, az Internet Assigned Numbers Authority (IANA) bejelenti, hogy az utolsó öt címblokkot egyenlően osztották el az öt regionális internetes nyilvántartással (RIR), és ezért már nincsenek szabad címblokkok. A2011. április 15Az APNIC , az ázsiai-csendes-óceáni régiót kiszolgáló RIR bejelentette, hogy most már csak egy / 8 blokkja van (16,7 millió cím), és most csak korlátozott mennyiségű címet oszt ki a pályázóknak. Az Európát és a Közel-Keletet kiszolgáló RIPE NCC is ezt tette2012. szeptember 14. A fennmaradó RIR-ek 2013 és 2015 között kimerítik az IPv4-címek kiosztását a helyi internetes nyilvántartásokhoz (LIR-ek). A LIR-ek 2012-ben kezdik elfogyni az ügyfelek számára kiosztandó IPv4-címeket.
Az IPv6 a múlt tapasztalatai alapján az IP működésének néhány aspektusát is javítja.
Az IPv6 fő specifikációit 1995-ben tette közzé az IETF. Az újdonságok közül megemlíthetjük:
Az 1990-es évek elején világossá vált, hogy az Internet fejlesztése a rendelkezésre álló címek kimerüléséhez vezet ( RFC 1752). 1993-ban az IETF pályázati felhívást indított ( RFC 1550), és bejelentette az IP Next Generation (IPng) munkacsoport létrehozását .
Először az Simple Internet Protocol Plus (SIPP, RFC 1710), majd az IP Next Generation (IPng) nevet kapta, ezt 1994- ben választották ki több jelölt közül, és 1995-ben megkapta az IPv6 (IP verzió 6), az IP 5- ös végső nevét. az Internet Stream Protocol 2. verziójához (ST2) fenntartva az RFC 1819 által. Az IPv6 specifikációit eredetileg 1995 decemberében tették közzé az RFC 1883-ban, és az RFC 2460- ban véglegesítették .1998 december.
Az IPv6 működése nagyon hasonló az IPv4 működéséhez. A TCP és az UDP protokollok gyakorlatilag változatlanok. Ezt összegzi a "további 96 bit, semmi varázslat" képlet.
Az IPv6-cím 128 bit vagy 16 bájt , szemben az IPv4 32 bites / 4 bájtjával. Az IPv4-címekhez használt pontozott tizedes jelölést (például 172.31.128.1) elhagyjuk a hexadecimális írás helyett , ahol a 8 2 bájtos (csoportonként 16 bites) csoportot kettőspont választja el:
2001: 0db8: 0000: 85a3: 0000: 0000: ac1f: 8001A négy hexadecimális számjegyű csoportból egy-három vezető nulla elhagyható. Tehát a fenti IPv6-cím egyenértékű a következőkkel:
2001: db8: 0: 85a3: 0: 0: ac1f: 8001Ezenkívül elhagyható egy vagy több egymást követő 16, minden nulla bitből álló csoport egyetlen szekvenciája, azonban a kettőspontokat a kihagyott számjegyek mindkét oldalán megtartva, azaz két. -Pont "::" pár ( RFC 2373 és RFC 4291). Így a fenti IPv6-cím a következőképpen rövidíthető:
2001: db8: 0: 85a3 :: ac1f: 8001Egyetlen IPv6-cím többféle módon ábrázolható, például 2001: db8 :: 1: 0: 0: 1 és 2001: db8: 0: 0: 1 :: 1. Az RFC 5952 kanonikus ábrázolást javasol.
Meg kell jegyeznünk, hogy az IPv6-címek közül csak egy nulla bitsorozatot lehet kihagyni. Ellenkező esetben lehetetlen lenne azonosítani az egyes vastagbélpárok közötti nulla bit számát: ".
A hálózatok azonosítása a CIDR jelöléssel történik : az első hálózati címet egy "/" perjel követi, majd egy 0 és 128 közötti egész szám követi, amely a hálózati előtag hosszát bitekben jelöli , nevezetesen az említett hálózat által meghatározott közös címrészeket.
Az alábbiakban bemutatunk példákat az IPv6 hálózati címekre, azok meghatározott címkészleteivel:
Bizonyos IPv6-cím előtagok különleges szerepet töltenek be:
Előtag | Leírás | |
---|---|---|
:: / 8 | Foglalt címek | |
2000 :: / 3 | Internet útválasztható egyedi küldési címek | |
fc00 :: / 7 | Egyedi helyi címek | |
fe80 :: / 10 | Helyi címek link | Unicast a helyi linken ( RFC 4291) |
ff00 :: / 8 | Multicast címek | Multicast ( RFC 4291) |
A :: / 8 címről lefoglalt címek közül kettő észrevehető:
A 2000 :: / 3 címek a következőképpen különböztethetők meg:
terület | globális útválasztási előtag | alhálózati azonosító | interfész azonosító |
---|---|---|---|
bitek | nem | 64-n | 64. |
A változó méretű globális útválasztási előtag képviseli a cím nyilvános topológiáját , más szóval azt, amely a webhelyen kívül látható. Az alhálózati rész alkotja a privát topológiát . Az RFC 4291 azt jelzi, hogy az összes globális unicast címnek 64 bitesnek kell lennie az interfész azonosító méretének (IID), kivéve azokat, amelyek a bináris 000-vel kezdődnek. Pont-pont kapcsolatok esetén azonban lehetséges az a / 127 ( RFC 6164) használata. Az RFC 7421 leírja ennek az egységes méretű interfész-azonosítónak az architekturális választását, amely úgy tűnik, hogy messze meghaladja az alhálózat címzési igényeit.
HatályAz IPv6-cím hatóköre az érvényességi és egyediségi tartományból áll az RFC 4007 szerint.
Megkülönböztetünk:
Minden olyan interfésznek, ahol az IPv6 aktív, van legalább egy link-local hatókör-címe (fe80 :: / 10); a fe80 :: / 10 jelöléssel ellátott cím az egyedi küldést jelöli a helyi linken ( RFC 4291).
ZónaindexNem lehet több link-local címek különböző kapcsolatok ugyanazon a gépen, akkor távolítsa el a kétértelműséget biztosításával terület index ( RFC 4007), hogy mi adjunk a címet, miután egy százalék jelet: fe80 :: 3% eth0 fog megfelelni link-local cím fe80 :: 3 például az eth0 felületen.
IPv6 címblokkok hozzárendeléseA globális egyedi küldési címtérben (2000 :: / 3) az IANA / 12 és / 23 közötti méretű blokkokat oszt ki a regionális internetes nyilvántartásoknak , például az európai RIPE NCC -nek. Ezek a / 32 előtagokat terjesztik a helyi internetes nyilvántartásokba, amelyek aztán / 48 - / 64 blokkként hozzárendelik őket a végfelhasználókhoz ( RFC 6177).
Minden végfelhasználóhoz hozzárendel egy blokkot, amelynek mérete változik a / 64-től (egyetlen alhálózat ) a / 48-ig (65 536 alhálózat), mindegyik alhálózat gyakorlatilag korlátlan számú hosztot tartalmaz ( 264 ). Az 2000 :: / 3 blokk ami ⅛ th a címtartomány elérhető IPv6, tudjuk tehát létre 2 29 , illetve 500 millió / 32 blokk, az internetszolgáltatók és 2 45 , vagy 35.000 milliárd tipikus üzleti hálózatok (/ 48).
Az IPv6 csomag fejlécének mérete 40 bájton van rögzítve, míg az IPv4-ben a minimális méret 20 bájt, az opciók 60 bájtig terjednek, ezek a lehetőségek a gyakorlatban ritkák.
A mezők jelentése a következő:
Lehetséges, hogy egy vagy több kiterjesztés fejléc követi az IPv6 fejlécet. Az útválasztási fejléc lehetővé teszi például a forrás számára, hogy meghatározzon egy követendő meghatározott utat.
Összehasonlítás az IPv4-telAz IPv4-ben az útválasztóknak, amelyeknek át kell küldeniük egy olyan csomagot, amelynek mérete meghaladja a céllink MTU-ját , az a feladat, hogy szétaprózzák, vagyis több kisebb IP csomagra tagolják. Ez a bonyolult művelet CPU szempontjából drága az útválasztó, valamint a célrendszer szempontjából, és hátrányosan befolyásolja az átvitel teljesítményét, másrészt a töredezett csomagok érzékenyebbek a veszteségekre: ha csak az egyik töredék elvész, a teljes kezdeti csomagot újra kell küldeni.
Az IPv6-ban a köztes útválasztók már nem töredezik a csomagokat, és helyette visszaküldik egy ICMPv6 túl nagy csomagot , ezután a küldő gép felel a csomag feldarabolásáért. A Path MTU felfedezése azonban ajánlott a széttöredezés elkerülése érdekében.
Ez a változás leegyszerűsíti az útválasztók feladatát, kevesebb processzort igényel.
A linkek minimálisan megengedett MTU-ját szintén 1280 bájtra növelték (az IPv4 68-hoz , az RFC 791- hez képest az RFC meghatározza, hogy a gazdagépnek képesnek kell lennie egy újra összeállított 576 bájtos csomag fogadására.). Ha bármely link nem tudja támogatni ezt a minimális MTU-t, akkor egy konvergencia rétegnek kell lennie, amely felelős a csomagok töredezettségéért és újraszereléséért.
Az IPv4-hez hasonlóan az IPv6 fejlécen kívüli csomagok maximális mérete 65 535 bájt. Az IPv6-nak azonban van egy jumbogram me opciója ( RFC 2675), amely lehetővé teszi a csomagok maximális méretének 4 GB- ra való növelését, és ezáltal a nagyobb MTU-val rendelkező hálózatok előnyeit élvezheti.
Hosszabbító fejlécekAz IPv6 fejlécet számos kiterjesztés fejléc követheti. Ezek követik egymást, minden fejléc a következő természetét jelzi. Amikor jelen vannak, sorrendjük a következő:
Francia név | angol név | típus | Vágott | Leírás | RFC |
---|---|---|---|---|---|
komló komló után RFC 2460 | Hop-By-Hop opciók | 0 | változó | Olyan opciókat tartalmaz, amelyeket minden közlekedési útválasztónak tiszteletben kell tartania, például a jumbogram opciót. | RFC 2460, RFC 2675 |
útvonalválasztás | 43 | változó | Lehetővé teszi az útválasztás módosítását a forrásból, amelyet különösen a Mobile IPv6 használ | RFC 2460 RFC 3775, RFC 5095 | |
Töredék | 44. | 64 bit | Információt tartalmaz a széttöredezettségről. | RFC 2460 | |
Hitelesítési fejléc (AH) | 51 | változó | A fejléc hitelesítéséhez szükséges információkat tartalmazza, lásd: IPsec . | RFC 4302 | |
Biztonsági hasznos terhelés (ESP) beágyazása | 50 | változó | Információt tartalmaz a tartalom titkosításáról, lásd: IPsec . | RFC 4303 | |
Úticél opciók | 60 | változó | Olyan opciók, amelyeket a végső célnak kezelnie kell. | RFC 2460 | |
Nincs fejléc az RFC 2460 szerint. | Nincs következő fejléc | 59 | üres | Jelzi, hogy nem következik hasznos teher. | RFC 2460 |
A többi lehetséges érték ugyanazt a konvenciót követi, mint az IPv4 fejléc Protokoll mezője .
A " Neighbor Discovery Protocol vagy ND, RFC 4861" protokoll társítja az IPv6-címeket egy szegmens MAC-címeivel, például az ARP az IPv4-hez. Lehetővé teszi továbbá az útválasztók és az átirányított előtagok, az MTU felfedezését a duplikált címek, az elérhetetlenné vált gazdagépek, valamint a címek és esetleg a rekurzív DNS-kiszolgálók címeinek automatikus konfigurálása (RDNSS, RFC 5006). Az ICMPv6- on alapul .
Az alhálózatban a címek hozzárendeléséhez számos módszer létezik:
Kézi konfigurálás az adminisztrátor rögzíti a címet. A teljesen 0-ból vagy 1-ből álló címek nem játszanak különös szerepet az IPv6-ban. Automatikus konfigurálásHontalan ( Stateless Address Autoconfiguration , SLAAC):
Állammal:
Amikor ezt a protokollt az 1990-es években kidolgozták, az internet nem volt annyira fejlett, és nem foglalkoztak a személyes adatok védelmével és a magánélet kérdésével. De a 2010-es években a hálózati kártya MAC-címének használata az IPv6-cím összeállításához aggályokat vetett fel a személyes adatok védelme miatt, mivel a MAC-cím egyedülállóan azonosítható. Ennek a felügyeletnek a leküzdése érdekében a protokoll fejlődött, és bevezettek más módszereket a címek létrehozására, az úgynevezett adatvédelmi kiterjesztésekre :
Lehetséges ideiglenes címek használata, amelyeket ál-véletlenszerűen generálnak és rendszeresen megváltoztatnak ( RFC 4941). Annak érdekében, hogy idővel stabil címre legyen szükség, 2017 óta lehetséges, sőt ajánlott egy titkos kulcsból és a hálózati előtagból ( stabil privátnak nevezett , RFC 7217) származó cím használata . Mindig lehetőség van egy szolgáltatás használatára az IPv6-címek kiszolgáló általi automatikus kiosztására, hasonlóan az IPv4-hez, DHCPv6-tal.
Az a multicast , amely csomagot hirdet egy csoportnak, az IPv6 kezdeti specifikációjának része. Ez a funkció az IPv4-ben is létezik, ahol az RFC 988 adta hozzá 1986-ban.
Már nincs IPv6 sugárzási cím , helyébe a kívánt alkalmazásra jellemző multicast cím lép. Például az ff02 :: 101 címet arra használják, hogy kapcsolatba lépjen az NTP szerverekkel . Ez lehetővé teszi a gazdák számára, hogy az általuk nem használt protokollokhoz vagy alkalmazásokhoz szánt csomagokat szűrjék anélkül, hogy meg kellene vizsgálniuk a csomag tartalmát.
Ethernet szinten OUI előtagok sora van fenntartva a multicast IPv6 címek számára (33: 33: xx). A multicast csoport MAC címe ebből a 16 bitből áll majd, amelyet az IPv6 multicast cím utolsó 32 bitje követ. Például az ff02 :: 3: 2 cím megegyezik a 33: 33: 00: 03: 00: 02 MAC-címmel. Bár sok multicast csoport ugyanazt a MAC címet használja, ez már lehetővé teszi a hatékony szűrést a hálózati adapter szintjén.
Bár az IPv6 esetében kötelező a kapcsolati szintű csoportos küldés támogatása, a csoportos küldési csomagok szegmensen túli továbbításához az internetszolgáltató belátása szerint olyan útválasztási protokollokat kell használni, mint például a PIM .
A Multicast Listener Discovery protokoll lehetővé teszi az aktív csoportok azonosítását egy szegmensben, például az IGMP for IPv4.
A legegyszerűbb Ethernet kapcsolók a multicast képkockákat úgy kezelik, hogy azokat sugárzott keretekként sugározzák . Ezt a viselkedést javítja az MLD-nél történő snooping, amely csak a csoport iránt érdeklődő állomásokra korlátozza az adást, például az IGMP Snooping for IPv4.
Míg az IPv4-ben nehéz globális multicast-címeket lefoglalni, az RFC 3306 az interneten minden egyes útválasztható előtaghoz társít egy multicast / 96-os blokkot, vagyis minden szervezetnek automatikusan 4 milliárd dollárja van. 'Nyilvános multicast címek. Az RFC 3956 leegyszerűsíti a találkozási pontok megvalósítását a multicast összekapcsolásokhoz is.
A multicast címek felépítése az unicast előtagon alapulva a következő példák egyikét öltheti:
A tartománynévrendszerben a gazdagépnevek az AAAA rekordot használó IPv6 címekhez vannak társítva.
www.ipv6.ripe.net. IN AAAA 2001:610:240:22::c100:68bA fordított felvételt az ip6.arpa alatt hajtjuk végre, a kanonikus formában írt cím megfordításával ( RFC 3596): először a legkevésbé jelentős nibble kódolódik:
b.8.6.0.0.0.1.c.0.0.0.0.0.0.0.0.2.2.0.0.0.4.2.0.0.1.6.0.1.0.0.2.ip6.arpa. IN PTR www.ipv6.ripe.net.A szabvány első verziója az ip6 .int utótag használatát tervezte .
A fordított tartománynév felépítéséhez használt mechanizmus hasonló az IPv4-ben alkalmazotthoz, azzal a különbséggel, hogy a pontokat minden egyes nibble ( RFC 3596) bit (vagy 4 bit nibble ) között használják, ami meghosszabbítja a domént.
A komplexebb bitcímkéket ( RFC 2673), a DNAME és A6 ( RFC 2874), amelyek leküzdik a felhatalmazás korlátozását egy rágcsálási határon, kísérleti jellegűnek tekintik, és támogatásuk ritka ( RFC 3363, a szokatlan A6 rekordot „történelmi” -re helyezték át) állapotát az RFC 6563 2012-ben).
A fordított felbontást beléptető rendszerek, valamint diagnosztikai eszközök, például a traceroute is használhatják .
Az IPv6 nem támogatja a címfordítás használatát a hálózati átláthatóság megőrzése érdekében ( RFC 5902), a címek mentéséhez már nem szükséges.
Az IPv6 mechanizmusokat biztosít ugyanazon IPv6-cím megtartásához egy olyan géphez, amely különböző hálózatokhoz csatlakoztatható, miközben a lehető legnagyobb mértékben elkerüli a háromszög alakú útválasztást.
Az IPv4 és az IPv6 címek nem kompatibilisek, ezért problémát jelent a csak IPv6 címet használó gazdagép és a csak IPv4 címet használó gazdagép közötti kommunikáció. Az átmenet az, hogy az IPv4 gazdagépeket kettős veremmel kell ellátni , vagyis mind az IPv6, mind az IPv4 címeket.
Az IPv6 elérésének legegyszerűbb módja, ha feliratkozik egy olyan internetszolgáltató választására, amely natív módon kínál IPv6-ot , vagyis alagutak igénybevétele nélkül.
Ellenkező esetben és egy átmeneti fázis alatt lehetőség van IPv6-kapcsolat megszerzésére egy alagúton keresztül. Az IPv6-csomagokat ezután IPv4-csomagokba kapszulázzák, amelyek az internetszolgáltató hálózatát egy IPv6-ot és IPv4-t támogató kiszolgálóhoz vezethetik, és ahol azokat lezárják. Az alagutak, tehát egy átfedő hálózat használata káros hatással lehet a teljesítményre.
Statikus alagutakSzámos " alagútközvetítő " típusú szolgáltatás érhető el, amelyek általában regisztrációt igényelnek. Idézhetjük a SixXS-t vagy a Hurricane Electric-t.
A használt protokollok a következők lehetnek:
Az alagútbeállító protokoll ( RFC 5572) megkönnyíti az alagút létrehozását, és lehetővé teszi a mobilitást és a hitelesítést. Az AICCU (in) által használt Tunnel Information and Control protokoll automatizálja az alagutak létrehozását.
Automatikus alagutakLehetőség van olyan dupla veremű szerverek használatára, amelyek alkalmazásszintű átjáróként (ALG) működnek, például web- proxy szerverként .
A NAT-PT a hálózati címfordítást és a DNS-kiszolgálót ötvözi az IPv4 rendszerek és az IPv6 rendszerek közötti kommunikáció lehetővé tétele érdekében. Az RFC 2766 meghatározza, de az RFC 4966 problémák miatt elavult .
A többhomályosítást az jelenti, hogy egy hálózatnak több tranzitszolgáltatója legyen az internet-hozzáférés megbízhatóságának növelése érdekében. Az IPv4-ben ez általában úgy valósul meg, hogy saját AS- számmal , szolgáltatótól független (PI) IP-címtartománnyal rendelkezik, és a BGP használatával dinamikusan cseréli az útvonalakat az egyes szolgáltatókkal.
A multihoming végrehajtásának ilyen módja AS számokat emészt fel, és növeli az internetes útválasztási tábla méretét a nem összesíthető PI előtagok miatt.
A multihoming szabványosítása az IPv6-ban késik, az IPv6 architektúra egyik kezdeti célja az, hogy csak a Provider Aggregable (PA) típusú címeket használja az internetes útválasztási tábla méretének csökkentésére. Ezt szem előtt tartva a többhomályosítást annyi PA-cím kiosztásával értük el, ahány szolgáltató van, az IPv6-mechanizmusokat, például az automatikus kiosztást és a címek korlátozott élettartamát, amely megkönnyíti a beszállítók változásához kapcsolódó címváltozásokat. Ezért a regionális internetes nyilvántartások egészen a közelmúltig nem terjesztettek PI blokkot az IPv6 számára.
2009-ben a RIR-ek, a RIPE NCC-hez hasonlóan , megváltoztatták politikájukat azzal, hogy beleegyeztek a PI-blokkok kiosztásába azoknak a vállalatoknak, amelyek több szolgáltatóhoz szeretnének csatlakozni, a minimális PI-blokk mérete / 48, míg a blokk mérete PA / 32. Ez lehetővé teszi a multihoming ugyanolyan végrehajtását, mint az IPv4 esetében.
Más lehetséges megközelítések az azonosító és a lokátor elválasztásán alapulnak ( Identifier / Locator Separation ):
Ez egy kutatási téma az Internet Kutatási Munkacsoport (en) Routing Research munkacsoportjában .
Első fázisban az internetszolgáltatók olyan alagutakat használnak, amelyek IPv6-csomagokat tokoznak IPv4-csomagokba (6in4 vagy GRE útján) az útválasztók olyan csoportjainak áthaladásához , amelyek nem támogatják az IPv6-ot. Ha lehetséges, a cserék natív módon zajlanak , az IPv4 és az IPv6 segítségével, amelyek ugyanazon a linken vannak egymás mellett. Mindaddig, amíg az útválasztók frissülnek az IPv6 támogatására, nincs szükség külön infrastruktúrára az IPv6 számára, mivel az útválasztók mind az IPv4, mind az IPv6 forgalmat kezelik.
Mivel 2004. július, Az ICANN elfogadja a névszerverek IPv6-címmel ( ragasztórekordokkal ) történő integrálását a gyökérzónában. Az első legfelső szintű IPv6 DNS-kiszolgálóval rendelkező domainek a .kr és .jp , .fr hamarosan következnek.
Ban ben 2008. február, Az ICANN hozzáadta az IPv6-címeket a tizenhárom DNS-gyökérkiszolgáló közül hathoz, és az „i” -et 2010-ben adták hozzá. Másrészt 2010-ben a 283 legfelső szintű tartományból 228 rendelkezik legalább egy IPv6-címmel rendelkező szerverrel. A regisztrátoroknak azonban frissíteniük kell szoftverüket, hogy támogassák az IPv6 szerverek és az esetleges AAAA ragasztórekordok delegálását .
A fő névszerverek, mint például a BINDv 9, támogatják az AAAA rekordokat, valamint a kérelmek továbbítását IPv6-on keresztül.
Az UDP DNS-csomagjainak mérete 512 bájtra korlátozódik ( RFC 1035), ami problémákat okozhat abban az esetben, ha a válasz különösen nagy. Ezután a szabvány előírja, hogy TCP kapcsolatot használnak, de egyes tűzfalak blokkolják az 53 TCP portot, és ez a kapcsolat több erőforrást emészt fel, mint az UDP-nél. Ez az eset különösen a gyökérzónában található névkiszolgálók listájára vonatkozik. Az EDNS 0 ( RFC 2671) kiterjesztés nagyobb csomagméret használatát teszi lehetővé, támogatása mind az IPv6, mind a DNSSEC számára ajánlott.
Az útválasztási protokollok, például a BGP ( RFC 2545), az OSPFv 3 ( RFC 5340), az IS-IS ( RFC 5308) és az MPLS ( RFC 4798) frissültek az IPv6 számára.
A TCP és az UDP protokollok IPv4 néven működnek. A vezérlő kód kiszámításához használt álfejléc azonban módosul, és tartalmazza a forrás és a cél IPv6 címeket. Az UDP esetében is kötelező a vezérlőkód használata. Kisebb módosítások történtek a jumbo csomagok támogatásában ( RFC 2675).
Az IEEE 802 típusú linkréteg protokollok alkalmasak az IPv6 szállítására. A Ethernet szinten például az érték a típus mező hozzárendelt IPv6 0x86DD ( RFC 2464).
Az NBMA (en) hálózatokon, például az X.25 vagy a Frame Relay , adaptációkat terveznek a Neighbor Discovery működésének lehetővé tétele érdekében .
A (z) CableLabs konzorcium az IPv6 kábelmodemekre vonatkozó specifikációkat a DOCSISv 3.0- ban tette közzé2006. augusztus. A DOCSIS 2.0 verziójában nincs IPv6-támogatás. Az úgynevezett "DOCSIS 2.0 + IPv6" verzió azonban létezik, és csak firmware-frissítést igényel.
Az xDSL technológiák esetében az RFC 2472 meghatározza az IPv6 tokozását PPP-n keresztül. Az ARM- nek támogatnia kell az IPv6-ot is.
Általában berendezések működik a kapcsolat réteg , például ethernet kapcsolók , nem kell egy frissítést az IPv6 támogatás, kivéve talán távirányító és kezelését és optimalizálását. Multicast műsorszórást MLD-bepillantás .
A hozzáférési rendszereket általában felül kell vizsgálni az IPv6, a címkiosztó eszközök és a címregisztrációs adatbázisok tekintetében.
A XXI . Század eleje óta az összes főbb operációs rendszert ( GNU / Linux , Mac OS X , Microsoft Windows , BSD , Solaris , HP-UX stb.) Frissítették az IPv6 támogatására, és ez a helyzet egyéb beágyazott rendszerek, például Symbian , QNX , Android , Windows Mobile vagy Wind River .
A Windows Vista az alapértelmezett konfigurációban támogatja az IPv6-ot, az IPv4-beállításokat ugyanazon a síkon tárja a grafikus felhasználói felület IPv6-beállításaira, és az IPv6-hoz önálló verem helyett új kettős verem TCP / IP-t használ. Ez a támogatás képezi a HomeGroup és a DirectAccess alapját a Windows 7 rendszerben .
A router szinten , Cisco kínál IPv6 támogatás 2001 óta IOS 12.2, ez is a helyzet újabb változatai szoftver főbb gyártók, mint a Juniper Networks , az Alcatel-Lucent és a Redback Networks .
Egyes CPE-k azonban továbbra sem kompatibilisek az IPv6-tal, ami szükségessé teszi az alagutak konfigurálását.
A hálózathoz csatlakoztatott alkalmazásokat módosítani kell, hogy kompatibilisek legyenek az IPv6-tal. A forráskód frissítés mértéke attól függ, hogy az alkalmazások milyen módon használják a címeket. Ez lehet egyszerű helyettesítés, de bonyolultabb módosítás is, ha a címet adatbázisban tárolják, vagy a beléptetés ellenőrzésére használják.
Ha nem lehetséges az alkalmazás gyors frissítése, az átállási technikák lehetővé teszik az IPv4-alkalmazások számára, hogy kommunikáljanak az IPv6-ügyfelekkel:
Számos alkalmazást már portáltak. Ez különösen érvényes az olyan böngészőkre , mint az Internet Explorer (a 7. verzió óta, részben a 6. verzióhoz), a Mozilla Firefox (1.0), az Opera (7.20b), a Safari és a Google Chrome , a Mozilla Thunderbird mail kliens (1.0), Apache webszerver (1.3.27 / 2.0.43), Exim mail szerver (4.20) stb.
RENATER kísérletezni kezdett IPv6 1996 a G6bone hálózat, a francia megfelelője a globális 6bone hálózat , amely ugyanebben az évben elkezdődött. Ez a teszthálózat főleg alagutakat használt. A Renater 2 hálózati IPv6 pilot szolgáltatás natív IPv6-ot kínál ATM-kapcsolatokon keresztül 2002-ben.
internet szolgáltató | Telepítés dátuma | A hozzárendelt előtag hossza | MTU | Megjegyzések |
---|---|---|---|---|
Nerim | 2003. március | / 48 | 1500 PPPoA-ban, 1492 PPPoE-ben | |
Ingyenes | 2007. december | / 61 | 1480 szétválasztott ADSL-ben , nem elérhető szétválasztva | 6. az ADSL-ben |
FDN | 2008. november | / 48 | 1 492 PPPoE-ben | |
SFR | 2011 vége (béta in 2011. június)
2013 vége (FTTH) |
/ 64 | ? | L2TP alagút |
Megszámolható | 2012 eleje | ? | ? | DOCSIS 3.0 |
OVH | 2012 közepe | / 56 | 1500 IPoE-ben (szétválasztva), 1 492 PPPoE-ben | előtag delegálás ( RFC 3633) a DHCPv6 részéről |
narancs | Wanadoo tesztek 2005-ben; testreszabott ajánlatként 2010 óta kínálják a vállalati piacon az Orange Business Services márkanév alatt , azóta belső tesztek2014. július, Az IPv6 telepítése a nagyközönség számára 2016 elején kezdődött a szálas és VDSL ügyfelek számára. | / 56 | 1500 | A Livebox Playt IPv4 és IPv6 kompatibilisként hirdetik. |
Bouygues Telecom | 2017-ben szétválasztott ADSL-re, 2018-ban az FTTH-ra tervezték | / 60 | 1500 | IPv6 előtag-delegálás a Bbox-on 2018-ban |
Zeop | 2014. július 22 | / 56 | 1500 | Az első IPv6 operátor Réunionban |
Quantic Telecom | 2013 | / 48 | ? | ? |
K-Net | 2012 | / 56 | 1500 | |
Orne THD | 2019 | / 56 | 1500 | Az első operátor, amely 100% -os IPv6-ot engedélyezett az összes ügyfél számára |
Az ARCEP 2019-es éves jelentése szerint a négy fő francia szolgáltató (Bouygues Telecom, Free, Orange, SFR) a tulajdonában lévő IPv4-címek körülbelül 94–99% -át már kiosztotta 2019. június.
Források: Arcep |
Források: Arcep |
A Svájcban , amellett, hogy az egyetemi hálózat üzemeltetője kapcsoló , több alternatív szolgáltatók telepített IPv6 azok a lakossági fogyasztók, amint a protokoll szabványosított, az egyik legfontosabb a Init7.
A jelenlegi üzemeltető, a Swisscom 2003-ban és 2004-ben telepítési kísérleteket hajtott végre a svájci IPv6 munkacsoport részeként, amelynek ő volt a vezetője, de az IPv6-ot csak a vállalat nemzetközi hálózata (IP-Plus) tartotta fenn. 2011-ben a Swisscom egy, az összes ügyfele számára nyitott kísérleti projektet indított a lakossági IPv6 telepítésére a 6. technológián keresztül .
A többi nagy svájci szolgáltató, nevezetesen a Sunrise, a Cablecom és az Orange hivatalosan még nem jelentett be terveket 2011. július, de a France Telecom 2009 októberében bejelentette, hogy Svájcot kísérleti országként használja bevetéseihez.
2000-ben a 6INIT program lehetővé tette az európai nemzeti kutatási és oktatási hálózatok (NREN-ek) összekapcsolását IPv6 PVC-k segítségével az ATM-en keresztül a TEN 155 európai kutatási hálózaton keresztül .
2003-ban a GENANT hálózat , amely a TEN 155- öt követte, kettős verem (IPv4 + IPv6) használatával készült. Az NREN-k közül tizennyolc natív módon csatlakozik az IPv6-hoz.
Az Európai Bizottság azt a célt tűzte ki maga elé, hogy 2008 végéig kötelezettségvállalásokat kapjon az Európai Unió 100 fő weboldal-üzemeltetőjétől, és cselekvési tervet tett közzé 2009. május.
A 2010 , a RIPE NCC (Europe) az a régió, amely bejelenti a legnagyobb számú IPv6-előtagokat.
A projekt IPv6 Érett a RIPE betartani a IPv6 Európában csillagok odaítélésekor a helyi internetes nyilvántartások , amikor néhány telepítési mutatókat elérni. Csillagokat kapnak a következő kritériumok mindegyikére:
Ban ben 2013. január, A LIR-ek 57% -a kapott IPv6-címblokkot, 19% -uk pedig a legmagasabb négy csillagot.
1996-ban a 6bone teszthálózat lehetővé tette az IPv6 technológiával való kísérletezést ( RFC 2471). Ez a hálózat alagutakra épült, és az útvonalakat a BGP4 + protokoll cserélte ki . A résztvevők a / 24, / 28 vagy / 32 előtagot kapták a 3ffe :: / 16 blokkban. A hálózatot 2006-ban szüntették meg ( RFC 3701) a natív kapcsolatok érdekében.
Ma sok webszerver elfogadja az IPv6-on keresztüli kapcsolatokat. A Google például IPv6-ból érhető el innen2008. március, ez a YouTube és a Facebook esetében is érvényes 2010 óta.
Vannak olyan IPv6-kiszolgálók is, amelyek általános szolgáltatásokat kínálnak, például FTP , SSH , SMTP , IMAP vagy IRC .
2009-ben számos globális szolgáltató kezdte telepíteni az IPv6-ot.
A Japánban , az NTT forgalmaz különféle IPv6 szolgáltatást kínál, valamint forgalmaz Flet telefonon .
A kormányzati beszerzési szabályozás kötelezővé teszi az IPv6 támogatását, különösen az Európai Unió államaiban és az Egyesült Államokban .
Az Egyesült Államokban a Comcast 2010-ben megkezdte a különféle technológiák tesztelését az IPv6 körül, a termelési hálózatán, az IPv4- címek végleges telepítésének és kimerülésének előrejelzésére számítva . Az IPv6-ot az Amerikai Egyesült Államok Védelmi Minisztériuma is használja .
A Kínai Népköztársaság érdeklődéssel figyeli az IPv6-ot. Célja az IPv6 kereskedelmi használatának megkezdése 2013-tól, szélesebb körű használata és összekapcsolása 2015-ig. A kínai IPv6-címek 2011-ben csak a globális IPv6-címek 0,29% -át teszik ki, míg Kína globálisan a harmadik helyen áll.
Az IPv6-ot néha az egyetlen összekapcsolási eszközként vetik ki Ázsiában a mobil mobil terminálokkal ; gyorsan így lesz Európában is, amikor a régi, GSM protokollokon alapuló összekapcsolási megoldásokat IP megoldásokkal kell felváltani. Ezen túlmenően, amint a mobilfelhasználások az állandó IP-kapcsolatok felé fejlődnek, nagyon nehéz lesz nagyon sok mobil terminál ( okostelefon ) címzését IPv4-címzéssel (még NAT-nal is).
Egy OECD-jelentés közzé2010. áprilisazt jelzi, hogy az IPv6 átvétele még mindig alacsony, a felhasználók 0,25–1% -a használja az IPv6-ot. A natív IPv6 forgalom az AMS-IX forgalom 0,3% -át teszi ki . 2009 végén 1851 AS IPv6 szám volt látható, a szám két év alatt megduplázódott.
Ban ben 2010. december, A Google becslése szerint az internetes keresési szolgáltatásának IPv6-felhasználóinak száma körülbelül 0,25% lenne.
A Wikipédia eseteA Wikipedia csapatai 2008 óta, 2006-os kísérlet után, 2008 óta készítik elő ezt a technikai szempontot. A folyamat előrehaladásának nyomon követésére szolgáló oldalt hoztak létre.
Miután az alapítvány részt vett a 2011-es tesztnapon, a Wikipedia lehetővé teszi a felhasználók számára, hogy az indulás napján teljes mértékben kihasználhassák az IPv6 használatával nyújtott szolgáltatásait.
Az IPv6 világnapjaA 2011. június 8az Internet Society (ISOC) globális IPv6-napnak adott otthont, amelynek során az eladókat és az oldalakat arra bátorították, hogy teszteljék a technológiát. A Google, a Facebook, a Yahoo!, Az Akamai és a Limelight Networks részt vett ezen az eseményen. A Google becslése szerint a felhasználók 99,95% -át nem érinti ez a teszt. A Yahoo által bemutatott statisztikák azt mutatják, hogy webhelyük felhasználóinak 0,022% -át érintették, míg 0,229% -uk használta az IPv6-ot.
Jogalkotási evolúcióFranciaországban a digitális köztársaságra vonatkozó törvény kötelezővé teszi az IPV6 - val való kompatibilitást a Magyarországról eladott termékekről1 st január 2018.
Néhányan, például Randy Bush, kritizálták az IPv6-ra való áttérés fázisának kidolgozását, jelezve, hogy az átmenet nehézségeit és költségeit minimalizálták, az IPv6-címeket túl nagyvonalúan osztották szét, hogy a jelenlegi forgalom szintje nem állíthatjuk, hogy az útválasztók ugyanolyan teljesítményre képesek, mint az IPv4, a protokoll-adaptáció nem teljes (különösen az SNMP és a tűzfalak), és hogy a várt előnyöket (a NAT megszüntetése és az Internet Routing Table Aggregation szempontjából) túlértékelték.
Másrészről, néhány olyan operációs rendszer, amely kettős veremmel rendelkezik, de nem működik működő IPv6-kapcsolattal, rendellenes késéseket okozhat az IPv6-címmel és IPv6-címmel rendelkező szerverek elérésekor. IPv4-cím, az IPv6-címet prioritásként használva mielőtt meghatározott idő után igénybe veszi az IPv4-címet.
2011-ben bizonyos hozzáférés-szolgáltatók peering- politikája az IPv6 Internet felosztásához vezetett. A Hurricane Electric (AS 6939) felhasználói nem kommunikálhatnak például a Cogent (AS 174) vagy a 3. szint (AS 3356) felhasználókkal. Ez a probléma időnként az IPv4 internetet is érinti.
Fékek a kioldáskorAz IPv6 telepítésének akadályai többek között a következők:
Ami az IPv6 támogatásának fejlesztését illeti a tartalom- és szolgáltatók körében, a problémát néha összehasonlítják a csirke és a tojás problémájával:
Ben megjelent tanulmány szerint 2009. október, a szállítók a következőket állapítják meg a fő akadályként:
A fő fejlődési tényezők a következők:
Az IPv6-ot telepítő internetszolgáltatók problémáival kapcsolatban:
Általánosságban elmondható, hogy a nagyközönségnek szánt piaci termékek nem frissíthetõk.
2014-ben az IPv6 támogatása még nem kritériuma a végfelhasználónak. Amikor egy nagyobb alkalmazás már nem lesz elérhető az IPv4-ben, akkor ennek a kritériumnak a fontosságát kétségtelenül felül fogják vizsgálni. A vállalatok azonban figyelmesebbek erre a problémára, és kerülik az olyan beruházásokat, amelyek összeegyeztethetetlenek lehetnek az IPv6-tal.
A csak egy IPv6-címmel rendelkező ügyfelek 2014 körül jelenhetnek meg, ezért a csak egy IPv4-címmel rendelkező internetes szerverekhez való kapcsolódás problémája a gyakorlatban felmerül azoknak az internet-ügyfeleknek, akiknek nincs IPv4-címük. Kettős verem (IPv4- és IPV6-címek). Az IPv6 szerverekhez való hozzáférés az IPv4 kliensektől szintén technikai kihívást jelent.
Így a problémák már Láthatóak, különösen a mobil internetelérés vonatkozásában , amely gyakran csak nem útválasztható magán IPv4-címeket oszt ki, de csatlakozik a hozzáférési hálózat üzemeltetője által biztosított HTTP proxy szerverekhez, néha kiábrándító teljesítményekkel és a hozzáférés korlátozásának problémáival. az ilyen típusú alagutak által támogatott kommunikációs protokollok, de az ideiglenes munkamenetek stabilitása is. A dinamikus NAT-ot használó más megoldásoknak van egy másik problémája a NAT útválasztókban elérhető portok éhínségével kapcsolatban, amelyeket több IPv4 kliens oszt meg az optimális használat érdekében a jelenlegi internet egyre interaktívabb alkalmazásaihoz, és amelyek minden felhasználó számára sok portot igényelnek; az alagútban történő protokollfordításon alapuló egyéb megoldások (6to4 vagy Teredo) szintén hasonló teljesítmény- és megvalósítási költségproblémákat vetnek fel, amelyeket csak a natív IPv6-os telepítés tudna megoldani jobb kompromisszummal a teljesítmény, a megvalósítás költsége és az üzemeltetési költségek között: léteznek a 3G mobil hozzáférésen , és e hálózatok ügyfelei még nagyon mérsékelt használat esetén is megfigyelik őket (amikor a hozzáférés költsége már magas), a 4G + hálózatok következő szintjére való áttérés ( például LTE ) nem lehet gazdaságilag életképes anélkül, hogy átváltanánk a natív IPv6 útválasztásra , alagút- vagy adaptációs proxy nélkül, amikor csak lehetséges (sok alkalmazást és weboldalt úgy kell adaptálni, hogy közvetlenül elérhetők legyenek az IPv6-ban, anélkül, hogy ezeket az adaptációkat meg kellene tartani, ha natív IPv4-hozzáférés nélküli ügyfeleik számára elfogadható teljesítményt kívánnak fenntartani).
Bár egyes berendezéseknek csak firmware- frissítésre lenne szükségük az IPv6 számára, nem biztos, hogy gyártóik befektetnek erre az útra, amikor az IPv6 Ready termékek értékesítése jövedelmezőbbnek bizonyul.