Az IPv6-tal 199x-ben (x>=8, pontosan sajnos már nem emlékszem) találkoztam először. Egy IBM 2210-es routeren jött velem szembe (ezúton is köszönet érte a CERN-ben dolgozó honfitársainknak), és nem értettem, hogy miért van rá szükség, hiszen az IP(v4) tökéletes, ráadásul még értem is.
Ebből a két mondatból már kiderülhetett, hogy nem szolgáltatói környezetben éltem akkoriban, naív, meg picit tudatlan is voltam a bináris világ ügyeit illetően (legalábbis ami ezt az internet nevű izét illeti, a FidoNet és a BBS pár évvel azelőttig sokkal mélyebb nyomot hagyott bennem).
De a világ rengeteget változott, én is hihetetlenül sokat fejlődtem, és ma már pironkodás nélkül vállalom: az égvilágon semmihez sem értek (De bármit megcsinálok! Remélem olvassák ezt az emberiség szellemi, genetikai elitjének megmentésén fáradozó űrlények is, és kapok jegyet az űrhajóra, közlegénynek tuti jó leszek, csak mosogatni ne kelljen! :).
Muszáj volt tehát kicsit újra elővennem a témát (persze nem csak, pontosabban nem pont ezért :), hogy aztán most már végre túljussak a ping ::1-en.

Az IPv6-ot hasonlíthatnám akár a szexhez is, mert hát tulajdonképpen korrekt az, amit az oviban mondtak róla, mégis, mire eljutottunk oda, hogy csináljuk is, már teljesen más lett (arról, aki évfolyamo(ka)t ugrott, és már oviban áttért a gyakorlati részre nem tudok nyilatkozni). És persze az igazság az, hogy a halvány emlékek is odalettek közben.
Azt mondták, hogy az IPv6 már 199x-ben (amikor legutoljára próbáltam) kész volt, de a valóság szerintem közelebb áll az ovis szex-témához. Ugyanúgy hívják, de közben mégis jelentősen megváltozott.

Kell ez nekünk?
Műszaki emberként viszonylag könnyű megérteni az IPv6 szükségességét, kiváltképp akkor, ha ennek az embernek a feladata éppenséggel a RIPE-pal való alkudozás, akik minden bizonnyal átköltöztek Hollandiából Skóciába, hogy minden nyelvterületen elterjedhessen végre a "skót" azon másik jelentése.

Végfelhasználóként azonban nehezebb a dolgunk, hiszen nem sok előny látszik. Az eddig viszonylag könnyen megjegyezhető címek helyett felfoghatatlan hexadecimális kódokat kell beírnunk (csak csendben jelzem: a DNS-t már rég feltalálták), amit még tovább rontanak azzal a duplakettősponttal, amit elsőre az IPv4-es anyatejen nevelkedetteknek nehéz megérteniük, ráadásul NAT sincs, ami <irónia>pedig az IPv4-et igazán biztonságossá tette</irónia> (hogy a prefixekről és hasonlókról ne is beszéljünk, már az ilyen IPv4-es /27, meg netmaszk is sokaknak az informatika csúcsa volt).

IPv6 látványosan
Mit tehetünk tehát, ha kevésbé hozzáértőként (esetleg bár szakiként, de nem ISP-nél keresve a napi folyékony kenyerünkre valót) könnyeden szórakozva meg akarjuk érteni az IPv4 és v6 jelenlegi státuszát?
Megnézhetjük például a 2012 című filmet (az agyunkat azért hagyjuk otthon, a Roland "cultural criminal" Emmerich név azért elmond mindent), amely egy létező apokaliptikus maja jóslatra épül, az eseményt 2012. december 21-ére téve. A népszerű "Mikor fogynak el az IPv4-es címek" számlálók szerint kb. 650 napunk van még, azaz ha kicsit optimistábbak vagyunk, akár még hihetünk is a maja jóslatban.
Erős a gyanúm, hogy ezt a filmet valójában hollywoodi IT-specialisták alkották azért, hogy megértse a világ milyen lesz az, amikor túl sokáig húzzuk az IPv4-et. Egyik pillanatban otthon pihensz a szobádban, majd a következőben egy An-225-tel próbálsz menekülni az összeomló IPv4 elől.
Hiába, a maják már több ezer éve előre látták, hogy 32 bit nem lesz elég, az IPv4-nek mennie kell, és eljön majd az új világ, 128 biten.
Ha valaki esetleg visszautazna valamikor 1974-be, feltétlenül vigyen magával egy 2012 DVD-t, vagy Blu Rayt, és adja oda Vint Cerfnek. Persze vigyen hozzá lejátszót, meg kijelzőt is.

Kapcsolódjunk!
Szerencsére az IPv6-hoz nem kell egy millió doll^Weurót fizetni, ma már egy sima ADSL-en is megkapjuk natívan, hiszen idén két szolgáltató (Externet, Magyar Telekom) is hozzáférhetővé tette a technológiát.

Ezt próbáltam ki egy ubuntus notebookkal, Magyar Telekom (T-Home) ADSL-lel (az azonos platform miatt működik a Telekom FTTH (Optinet) csomagjaival is, azaz ha szeretnénk, lehet natív 80/20 Mbps-es IPv6-os kapcsolatunk is otthon).

A notebookomon lévő Linuxszal kapcsolatban konzervatív (lusta?) vagyok, nem akarok command line cuccokkal (az ssh terminálon kívül) kínlódni, az elvárásom, hogy minden könnyen beállítható legyen, aztán működjön.
Sajnos ebben az Ubuntu nem túl jó (pld. külső display, mobilnet stb.), így túl sok reményem az IPv6 kapcsán sem volt, főleg miután átolvastam a Telekom IPv6-os használati tudnivalók oldaláról a megfelelő doksit, amely pppoeconf-fal állíttatja be velünk az elérést.
Gondoltam én azért megpróbálom a "dumb user" utat, így bedugtam a DSL modem ethernet portját (pár switchcsel, patchpanellel, és kábellel, és jó sok méterrel közöttünk :) a gépem seggébe, és megpróbálkoztam a gnome NetworkManagerrel egy sima ADSL kapcsolatot felépíteni. Fél órával később, mikor már minden létező opciót ki- és bekapcsoltam, és a google-lel több éves hibajegyeket találtam arról, hogy hányan szívtak már hasonlóval, inkább úgy döntöttem, hogy követem a pppoeconfos megoldást.

Először is létrehoztam egy profilt a

loginnévvel, kipróbáltam, működött. Majd ezután létrehoztam a leírásnak megfelelően a

-s hozzáférést is, majd regisztráltam a userid-met az erre kijelölt felületen. Ezt követően ponnal felhúztam az ipv6-os kapcsolatot is, és lőn:

ppp0      Link encap:Point-to-Point Protocol  
          inet addr:84.0.124.177  P-t-P:145.236.238.98  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:39 errors:0 dropped:0 overruns:0 frame:0
          TX packets:42 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:9304 (9.3 KB)  TX bytes:2704 (2.7 KB)
ppp1      Link encap:Point-to-Point Protocol  
          inet6 addr: 2001:4c48:100:1b8:11a0:8089:9531:83a5/64 Scope:Global
          inet6 addr: fe80::11a0:8089:9531:83a5/10 Scope:Link
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:354 errors:0 dropped:0 overruns:0 frame:0
          TX packets:370 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:108483 (108.4 KB)  TX bytes:47129 (47.1 KB)

már volt is natív IPv6-os global routed IP címem.

Az első dolgom volt, hogy megnézzem a HUP-ot (na jó, csaltam kicsit :) :

tcp6       0    805 2001:4c48:100:1b8:35069 2001:4c48:1:f800::6:80  ESTABLISHED
tcp6       0    808 2001:4c48:100:1b8:35068 2001:4c48:1:f800::6:80  ESTABLISHED
tcp6       0    809 2001:4c48:100:1b8:35071 2001:4c48:1:f800::6:80  ESTABLISHED
tcp6       0    816 2001:4c48:100:1b8:35067 2001:4c48:1:f800::6:80  ESTABLISHED

és egy-egy traceroute-ot az ftp.fsn.hu felé (v4 és v6-on):

 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 145.236.238.98                    0.0%    11    7.7   7.6   7.3   8.2   0.3
 2. 84.1.83.142                       0.0%    11    7.5   7.6   7.2   8.1   0.4
 3. 84.1.104.138                      0.0%    10    7.7   7.8   7.5   8.2   0.2
 4. 84.2.225.246                      0.0%    10    7.9   7.7   7.3   8.2   0.2
 5. 84.2.225.113                      0.0%    10    7.8   7.7   7.2   8.4   0.3
 6. 195.228.252.133                   0.0%    10    7.9   7.9   7.4   8.4   0.3

                                       Packets               Pings
 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 2001:4c48:0:12::2                 0.0%    12    8.1   8.2   7.6   8.6   0.3
 2. 2001:4c48:0:11::1                 0.0%    12    8.2   8.3   8.0   8.8   0.3
 3. 2001:4c48:0:1::2                  0.0%    11    8.8  11.5   8.8  23.5   4.6
 4. 2001:4c48:1:f800::11              0.0%    11   10.4  13.0   9.5  30.1   6.2

Mivel sokan aggódnak, hogy IPv6-on a kevésbé optimalizált adatutak (globális routing) miatt alacsonyabb lesz a sávszélesség, következő tesztként az ftp.netbsd.org-ról húztam le egy nagyobb fájlt IPv4-en és v6-on:

$ wget -4 -O /dev/null ftp://ftp.netbsd.org/ls-lRA.gz
--2009-11-23 10:48:59--  ftp://ftp.netbsd.org/ls-lRA.gz
           => `/dev/null'
Resolving ftp.netbsd.org... 204.152.190.15
Connecting to ftp.netbsd.org|204.152.190.15|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done.  ==> CWD not needed.
==> SIZE ls-lRA.gz ... 41147024
==> PASV ... done.    ==> RETR ls-lRA.gz ... done.
Length: 41147024 (39M)

100%[======================================>] 41,147,024  1.35M/s   in 32s     

2009-11-23 10:49:33 (1.24 MB/s) - `/dev/null' saved [41147024]


$ wget -6 -O /dev/null ftp://ftp.netbsd.org/ls-lRA.gz
--2009-11-23 10:47:41--  ftp://ftp.netbsd.org/ls-lRA.gz
           => `/dev/null'
Resolving ftp.netbsd.org... 2001:4f8:3:7:230:48ff:fec6:9aaa
Connecting to ftp.netbsd.org|2001:4f8:3:7:230:48ff:fec6:9aaa|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done.  ==> CWD not needed.
==> SIZE ls-lRA.gz ... 41147024
==> EPSV ... done.    ==> RETR ls-lRA.gz ... done.
Length: 41147024 (39M)

100%[======================================>] 41,147,024  1.30M/s   in 31s     

2009-11-23 10:48:15 (1.25 MB/s) - `/dev/null' saved [41147024]

Mint látható, ebben az esetben semmivel sem volt lassabb a letöltés, sőt.

Kicsit továbblépve megnéztem a google weblapját, amelyen az IPv6-on más (lásd: mozgó teknőc) grafikát mutató weboldalak hagyományát követve egy mozgó google logó látható, ha máshonnan nem, hát innen tudhatjuk, hogy IPv6-on nézzük a nagy testvér főoldalát.
A google-ön IPv6-on keresni túl nagy érdekességet nem jelentett, így oda is csináltam egy traceroute-ot:

                                       Packets               Pings
 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 145.236.238.98                    0.0%    22    7.2   7.7   7.1   8.4   0.3
 2. 84.1.83.142                       0.0%    22    7.7   7.9   7.3   8.5   0.3
 3. 81.183.247.98                     0.0%    22    7.9  10.7   7.3  37.4   8.0
 4. 209.85.242.228                    0.0%    22    8.0   8.2   7.2  14.4   1.4
 5. 209.85.248.39                     0.0%    22    7.8   7.8   7.3   8.7   0.3
    209.85.248.41
 6. 72.14.232.221                     0.0%    22   13.2  13.6   7.8  20.5   4.2
    72.14.238.101
    72.14.238.105
    72.14.232.217
 7. 74.125.87.99                      0.0%    22    7.5   9.2   7.5  29.5   4.5

                                       Packets               Pings
 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 2001:4c48:0:12::2                 0.0%    46    7.3   7.9   7.1   8.4   0.3
 2. 2001:4c48:0:11::1                 0.0%    45    8.1   8.6   7.5  22.9   2.2
 3. 2001:4c48:200::2                  0.0%    45    8.7  11.1   7.5  49.9   9.1
 4. ???
 5. ???
 6. 2001:4860:a003::68                0.0%    45   23.1  24.8  22.9  42.2   4.1

amelyből látható, hogy a Magyar Telekom nem csak IPv4-en, de IPv6-on is rendelkezik peeringgel az 1e100.net felé, így biztosak lehetünk benne, hogy ha IPv6-on érjük el a google-szolgáltatásokat, azok nem lesznek lassabbak, mint IPv4-en.
Ahhoz, hogy a google AAAA (IPv6-os host) rekordokat is publikáljon a DNS-ben, regisztrálnunk kell a névszervereinket, amely a Magyar Telekom esetében megtörtént:

$ host www.google.com cns0.telekom.hu
Using domain server:
Name: cns0.telekom.hu
Address: 84.2.44.1#53
Aliases: 

www.google.com is an alias for www.l.google.com.
www.l.google.com has address 74.125.87.103
www.l.google.com has address 74.125.87.147
www.l.google.com has address 74.125.87.99
www.l.google.com has address 74.125.87.104
www.l.google.com has address 74.125.87.105
www.l.google.com has IPv6 address 2001:4860:a003::68

így ha már IPv6-tal megyünk, nem kell az ipv6.google.com-ot használnunk, a normál hostneveken is fognak jönni a v6-os rekordok.

De mégis mekkora az IPv6?
Az IPv6-szkeptikusoktól sokszor lehet hallani, hogy ahogy az IPv4 címtér is elfogy(ott), úgy az IPv6 is el fog. Azok, akik értik a különbséget, és tudják, hogy nem 32*4=128-ról van szó, hanem 2^32*79228162514264337593543950336=2^128-ról szokták mindenféle hasonlattal (homokszemek, atomok stb.) magyarázni a dolgot, én azonban egy teljesen más megközelítésből szeretném bemutatni, hogy mennyivel is nagyobb az IPv6-os névtér.

Ahogy az a fentiekből is látszik, amikor IPv6-on kapcsolódunk, a szolgáltató egy ún. /64-es prefixet (vastagon szedve) oszt nekünk:
inet6 addr: 2001:4c48:100:1b8:11a0:8089:9531:83a5/64 Scope:Global
Ez azt jelenti, hogy amikor a gépünk felcsatlakozik az internetre, az IP cím első 64 bitjét az ISP adja, míg a második 64 bitet mi magunk választhatjuk meg szabadon.
Gondoljunk csak bele, ez azt jelenti, hogy a most 32 bites teljes IPv4-es címtérnél több, mint 4 milliárdszor annyi IP címből választhatunk csak az egyszem számítógépünk esetében!

Sajnos azonban ez a választási szabadság komoly problémákat rejt magában a szolgáltatói oldalon. A jó szolgáltató ugyanis rendben tartja a DNS-ét, ami azt jelenti, hogy minden, általa kiosztott IP címhez regisztrál PTR és A rekordokat, amelyek konzisztensek, azaz az IP PTR-jére adott választ feloldva az A rekordban az eredeti IP-t kapjuk vissza.
Ennek biztosítása a poolos (azaz pld. a DSL-es, kábeltévés, mobilos stb.) ügyfelekre eddig jellemzően úgy működött, hogy a DNS-ért felelős új címtartományok dedikálásakor (előtt) kézzel, vagy valami automatizmussal felvette ezeket a címeket a DNS-be, azaz valamilyen séma szerint létrehozta a PTR és A rekordokat.

Ez a rendszer IPv4-re teljesen jól működik, hiszen jellemzően egyik szolgáltatónak sincs annyi ügyfele, hogy az azoknak osztott poolokra ne tudna ilyen rekordokat tenni, amelyeket a DNS szerverek elsősorban memóriában (bind pld.), némelyik pedig valamilyen adatbázisban (pld. LDAP, SQL) tartják.

A probléma az IPv6-tal azonban az, hogy mint azt fent már említettem, minden felhasználó négy milliárdnyi internetet kap, amelyből az utolsó 64 bitet ő választja meg, azaz a szolgáltató előre (sőt, valójában utólag sem) nem tudja, hogy a felhasználó végül mire is tette le a voksát.
Azaz minden egyes neki osztott IP címre be kell regisztrálni az AAAA-t és PTR-t.
Hogy érezzük ennek a súlyát, használhatjuk az nsd nevű autoritatív névszerver memória-igény becslő eszközét, amely hozzávetőlegesen megadja nekünk a kívánt értékeket.
Ebbe beleírva egy ilyen /64-es prefix hostjait, 32 karakteres hostnévvel (hexa kódolásban az IP), 2^64 IP-re a következő értékek jönnek ki:

NSD memory usage estimate for 3.0.7 running on a 64 bit machine.
compiled with configure --disable-nsec3.
1 zones with 1 domains each.
Domain names average 4 labels and 32 wire format length.
Per name 2 NS records, 0 A, 18446744073709552000 AAAA.

755914244096 Gb	per domain.
755914244096 Gb	per zone for zone data.
3.5 kb	per zone for xfr, notify and options.
3.8 kb	for xfrd process (excl. buffers).
10 Mb	counted for buffers and malloc overhead.
1.1 kb	for zone option and apex (4 acls, 4 nameservers per zone).
755914244096 Gb	total memory size estimate for NSD server.
3023656976384 Gb	provision memory size estimate for the machine
(peak usage in worst case scenario, with reload and nsd-patch).

Azaz az nsd kalkulátora szerint egyetlen egy host csak forward (AAAA, a PTR itt még nem is szerepel) DNS bejegyzéseihez 720896 PB (Peta Byte!) memória kellene, worst case esetben pedig még több).
Azt hiszem ezt a számot nincs értelme kettővel (AAAA mellé PTR is kell), és aztán mondjuk két millióval (feltételezett pool méret egy ilyen méretű szolgáltatónál /ex has/) megszorozni, mivel már így is elképzelhetetlenül sok.

Ez tehát az én "homokszemes" IPv6-os példám.

/56-os forradalom
Az egyedi hostoknak járó /64 bár elképzelhetetlenül nagynak tűnik, de valójában még csak a jéghegy csúcsa. Mivel az IPv6-ban a NAT (azaz a címfordítás, amelyet az IPv4-es routerek (home/residential gatewayek) előszeretettel használnak arra, hogy az egyetlen publikus (globálisan route-olható) címük mögé tetszőleges számú privát (RFC1918-as) IP címet rejtsenek) elvileg nem létezik, kell, hogy legyen valami megoldás az otthonokban lévő többi eszköz felcsatlakoztatására IPv6-on is.
Természetesen van ilyen, ez pedig ugyanaz a módszer, amely IPv4-es DSL-nél is létezik, azaz a szolgáltató ad egy WAN interface IP-t a routernek, hozzárendel az ügyfélhez egy IPv4-es tartományt, amelyet aztán a PPP sessiont termináló routerben az ügyél WAN IP címére route-ol, amikor az aktív.
Az IPv6 esetében itt a WAN IP egy /64-es prefix (mint már tudjuk, utána mi választunk számot), amelyre "húzhatunk még lapot", konkrétan egy /56-os prefixű hálózatot, amelyből 256 darab /64-es prefixet oszthatunk tovább, amelyekre aztán már korlátlan (256*2^64 db.) gépet akaszthatunk.

Jó, de hogy néz ki ez a valóságban?
Akit jobban érdekel a műszaki háttér, megismerheti a Magyar Telekom trial rendszerének felépítését Dr. Varga Balázs Cisco Expón bemutatott előadásából.
A doksiból kiderül, hogy a /64-es címek osztása ún. "kvázi fix" módon történik, azaz két felcsatlakozással többnyire ugyanazt a /64-es prefixet fogjuk kapni, kivétel, amikor valamilyen hálózati átstrukturálás miatt ezt meg kell változtatni. Ezt a prefixet a hagyományos RADIUS AAA rendszerek adják.
A /56-os címeknél azonban más a működés, amely a trial rendszer idején elérhető hálózati megoldások azon limitációjából következik, hogy a /56-os sessionöket össze kell kötni a /64-es címekkel a teljes rendszerben (egészen az AAA-ig), azonban erre jelenleg nincs mód.
Ezt megkerülendő a /56-os címtartomány elkérésére a DHCP kliens egyedi azonosítójának (DUID - DHCP Unique Identifier) regisztrációja (ugyanazon az oldalon történik, mint az IPv6-képesség bekapcsolása) után nyílik lehetőségünk, amellyel megteremthetjük a kapcsolatot a /64-es és a /56-os prefixeink között.

Ezután a tényleges kapcsolódásra a "teljes" IPv6-os otthoni hálózathoz több módunk is van:

• ha egy gépünk van, közvetlenül az ADSL modemen, egyszerűen az IPv4-es sessionünk mellé indíthatunk egy IPv6-osat, amelyre egy /64-es global routed prefixet fogunk kapni
• ha egy routeren lóg az otthoni hálózatunk, de a routerünk nem tud IPv6-ot (elég esélyes), viszont tud PPPoE passthrough-t, ezt bekapcsolva a router mögül indíthatunk IPv6-os PPPoE sessionöket, amelyeknél megkapjuk a /64-es prefixünket
• a PPPoE passthroughnál az IPv6 sessiont indító eszköz kérhet /56-ot is, amelyet tovább oszthat a helyi hálózatban lévő többi PC-nek
• IPv6 képes router (pld. valami Linuxot futtató kis eszköz, vagy egy megfelelő OS-t futtató PC közvetlenül a DSL-en) használata esetén felhúzzuk a WAN /64-et, arra megkérjük a /56-ot, amelyől aztán szabadon oszthatunk a további hálózatainknak prefixeket

A fent hivatkozott előadásból látszik, hogy Balázsék teszteltek több operációs rendszert is, amelyek közül a Windows XP a PPPv6 támogatás miatt alapból kiesik, a Windows Vista és 7 alapvetően megfelelőnek találtatott (némi DNS jellegű problémával), míg az Ubuntu és FreeBSD volt a legkevésbé problémás.

IPv6 a szervereken
Szerencsére a szerver-OS-ek nagy részénél az IPv6 támogatás már "szakállasnak" mondható, így ha natív hozzáférést tudunk nekik szerezni, viszonylag kevés problémánk adódhat. Az IPv6-ban járatlanoknak azonban érdemes odafigyelniük arra, hogy ne alkalmazzák az IPv4-nél megtanultakat automatikusan erre a protokollra, hiszen sok tekintetben teljesen más a működésük.
A tapasztalatom szerint a problémás területeket elsősorban a szerver-processzek listenelése (lehet probléma az is, ha automatikusan elkezd az összes IPv6-os címünkön figyelni, vagy éppen az is, hogy egyáltalán nem teszi ezt. Sajnos még mindig sok program van, amelynek hiányzik, vagy hiányos az IPv6 támogatása, pld. ha nem állítunk be semmit, rendben figyel az összes IPv4 és IPv6-os címünkön, viszont ha már be szeretnénk állítani, hogy pontosan hol figyeljen, ezt csak IPv4-re tudjuk szabályozni), a csomagszűrők nem megfelelő beállítása (azon csomagszűrőkben, amelyekben régóta van IPv6 támogatás, a figyelmetlenségünk révén beengedhetünk IPv6-on olyat, amit nem szeretnénk), ide tartozóan az az általános és tipikus hiba az IPv4 világban, hogy a teljes ICMP-t tiltják (az IPv6 működéséhez viszont erre méginkább szükség van), és a működésbeli eltérések (pld. link-local címek használata, autoconfig, ARP helyett NDP stb.) jelentik.
Kiemelt figyelmet kell azonban arra is fordítani, hogy bár az IPv6 támogatás sok OS-ben akár egy évtizede is jelen van, a lassú terjedés miatt még mindig csak kevés hiba került napvilágra, így az IPv6 stack bekapcsolásával olyan extra biztonsági kockázatot vállalunk, amelyet gondosan fel kell mérni minden környezetben.

Az IPv6 a jövő, de már nem távoli
Összefoglalva a fentieket, mindenkinek csak ajánlani tudom, hogy gőzerővel kezdje el telepíteni az agyába az IPv6-ot, mert bár most még csak lassan indul, be fog gyorsulni a terjedése, amelyet elsősorban a nagy (növekedésű) internet penetrációval rendelkező országok, és az LTE mobilhálózatok fognak katalizálni.
Sajnos az IPv6 egyik legnagyobb hátránya még mindig a kevés elérhető tartalom (bár ha nyílt forráskóddal dolgozunk, szinte már alig találunk nagyobb letöltő site-ot, amely ne lenne IPv6-on elérhető), és a gyenge hozzáférhetőség.
De ezek együtt járnak, a későn ébredő szolgáltatók már idén elkezdték a technológia kipróbálását, bevezetését, azok pedig, akik évekkel később egy An-225-tel próbálnak majd felszállni egy épp összeomló reptérről egy gigantikus hamufelhőt előzgetve, hirtelen belehuppanva egy, a földbe nyílt több száz méteres kráterbe, hamarosan érezni fogják, hogy hiába a hat hajtómű, korábban kellett volna repülőre ülni.