/56-os forradalom - IPv6 otthonra

 ( bra | 2009. december 3., csütörtök - 10:37 )

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.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Köszönöm, érdekes volt.

bra, mindig meglep. Köszi a cikket!

Végülis pont ezért (szolgáltatni szeretnénk tartalmat) nyaggatuk nemrég az externetet ahol a webfelületen tudtunk egy szervernek IPv6-ot kérni, és kapni azonban lényeges adatok hiányoztak.

A válasz pedig:

Csak adsl vonalhoz jár IPv6 cím. Az Önök szerveréhez kapott cím rendszeradminisztrációs probléma.

T-Online-nál legalább őszinte választ kaptunk, 2010 előtt tuti nem, de még talán akkor sem (egyéb nem publikus válaszok is jöttek de mind azt sugallta, hogy NEM)

Tehát nem sok értelme van a IPv6 a tömegeknek programnak, hisz nincs mögötte releváns tartalomszolgáltatás, bár én már használok IPv6-ot de hobbi szinten, netrádió relaynek, stb, én sem érzem magam gurunak a témában, de ha nem kezdem el nem fogom tudni hogy mik a buktatók.

Szerencsére külföldi tartalom azért egyre több van, tehát értelme azért van. De nekem is nagy szívfájdalmam, hogy a szerverhostingban még nem alap az IPv6 elérés, hiszen ez egy nagyon fontos eleme az elterjedésnek.

Sajnos ez (nálunk legalábbis) nem elsősorban a "nem akarás" miatt van, hanem mert hiányoznak olyan védelmi megoldások az access layerben, amelyek a hostingnál elengedhetetlenek a működéshez...

Jó kis írás, én is köszönöm! :)

------------------------------
http://horrorfreaksubs.try.hu

Mindíg elhatározom, hogy most már tényleg beleásom magamat az IPv6 rejtelmeibe. De - mint Regős Bendegúz - mire végére értem a szándékomnak bele esett a fene. Ez az írás meg nagyon jó lett. Kicsit sikerült homályt gyújtani a sötétségben nálam. Bár most úgy érzem magamat mint egy fazék hideg töltöttkáposzta után: nagyon jó, de kell egy kis idő mire megemésztem. Köszönet érte!

Az IPv6-ot (mint protokollt) ez alapján elég nehéz megismerni/megtanulni, inkább azt próbáltam megvilágítani, hogy a szolgáltatói oldalról ez hogy látszik, ebben sokat segít Balázs előadása, erre a részre kívülről nem sok rálátást engednek a cégek...

szerintetek a mai vilagba visszalehet tartani 1 vilagvege-t eloidezo hirt? mitom en pl: lehet h egy nagy ustokos tart felenk ami 2012 er ide.. de visszatartjak az infot a panik elkerulese vegett

Simán, de nem kell parázni, fontos a pozitív életfelfogás, a becsapódás gyönyörű lesz, ráadásul nem gyatra CGI, hanem igazi. :)

Jah. És remélem, hogy a legjobb szögből fogom látni :)

--
robyboy

Szerintem a Windows nem felhasználóbarát.
Ha az lenne, nem utálnám.

Ez viszont egyszerű. Mindenki minél távolabb fog próbál jutni a helytől, odafelé üresek lesznek az autópályák, mehetsz akár 300-zal is, a kutya se fog megállítani. :)

es aki az odafele vezeto uton ellenkezo iranyba megy, na az az igazi ustokos :)

/* bocs az esetleges helyesirasi hidakert */

subscribe

Szerelem reggel, szerelem délben szerelem este... most már működhetne az a k..va szerver!

+1

"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!"

Tiszteletre méltó hozzáállás! Jómagam is ezt érzem már évek óta.
A szerénység erény, szaktudással párosulva meg követendő példa.

--
robyboy

Szerintem a Windows nem felhasználóbarát.
Ha az lenne, nem utálnám.

Csak nekem jön be az átalakított poszteren szereplő IPv6-os cím? :)


suckIT szopás minden nap! Hogyan csináljunk kevesebb, mint 500 ezerből 115 milliót?

Szia

Tudsz mondani olyan firmwaret, ami tud a pppoe-vel kerni ipv6-os cimet?

York.

------
"Nyugi! Minden a legnagyobb rendben csúszik ki a kezeim közül..."

Balázs előadása alapján Európában ez elég esélytelen. Gondolom a különböző routerekre tett linuxos firmware-rel (amelyben szabadon garázdálkodhatsz) ez kevésbé probléma (ha nincs is kivezetve, a lehetőség adott arra, hogy meghackeld magadnak).
De amúgy nem tudom, nekem sajnos nincs otthon semmim, amivel hozzáférhetnék natívan ehhez az IPv6-os lehetőséghez.

Tudom,nem igazi natív ipv6 feeling, de tunnelbrokeren keresztül bárkinek adott a lehetőség az ipv6 kipróbálására. Az openwrt-vel működő routerek (szappantartók) mindegyikével lehet ipv6-ot használni.

Sajnos ezeken a tunneleken jó eséllyel sokkal lassabb is lesz minden, ezért tényleg nem ugyanaz a feeling.

Nyilván, de nem vészes.A hurricane electric-nek (tunnelbroker.net) szinte minden nagy városban van tunnel-servere (Mon nincs Frankfurt a legközelebbi). És peeringelnek szinte mindenkivel. A tapasztalatom az hogy pont akkora a sebesség mintha ipv4-en töltenék le külföldről.
Ami még nagy jóság, hogy tudsz BGP-t is tesztelni ha van direkt allokált IPV6 tartományod és ASN-ed.

Külföldről lehet, ha a peeringek úgy alakulnak. De a hazai egyre növekvő számú IPv6-os tartalmak elérésében már hátrányban vagy. :)

A hup remekul olvashato rajta :)

Nade natív magyar IPv6-tal még remekebbül. :)

En is nagyon szeretnek, de kabeles netem van, szoval egy korbol kimaradok.

Váltani kell optikára. >;-)

ha lesz időm, mindenképp elolvasom, kösz.

érdekelne, hogy a tvnetwork mikor tervezi (?) az ipv6-ot...


szerintem.

Picit off: valaki tud DLINK DI-524 WiFi routerhez készült IPv6 firmware-ről? Netán nem is várható már hozzá?

Hozzatennem, hogy itt a szolgaltato a konnyebbik utat valasztja, es feltehetoleg Router Advertisement hirdetest nyom ki a felhasznalonak, holott PPP-nel sajat maga is oszthat cimet, es akkor nem kell attol felni, hogy a vegpontban kicserelodik a MAC address, merthogy az EUI64 vegulis ezt a 48->64bit lekepzest valositja meg amibol a /64-es cim vege generalodik. Ugyanugy a DNS is valoszinuleg PPP-vel jon, nem pedig az RA-bol, mert jelenleg nem tudok olyan implementaciorol ami RA hirdetesben levo RDNSS kiterjesztest megeszi es valoban beallitja a dns-t maganak.
A problema forrasa ott van linuxnal, hogy a statless address autoconfiguration-t a networking stack vegzi, dns beallitasokhoz meg userspace tool kell (resolv.conf edit), ennek megvalositasarol evek ota megy a flame.

Tisztabban latszik a problema, ha atterunk a kabeles szolgaltatokhoz, ahol nincs PPP, csak ethernet. Ott ket valasztas van: stateless autoconf + dnshekk, vagy egy stateful megoldas: DHCPv6, ami userspaceben fog mukodni, lehet mindenkinek osztott cime, es dns is lesz minden platformon.

--
http://bsdbased.com

Tök homály ez az IPv6, egy kérdésem van hirtelen: ráadásul NAT sincs - ez miért van így? Nem lehet, vagy nincs rá szükség, vagy mi az oka? Mi van ha mégis valakinek "indokolt"?
Egy példa, kicsit sántít de talán érthető: kapok a cégemtől egy VPN hozzáférést, tokennel (*), a VPN kiszolgáló beengedi a hosztot. Én szeretném az otthoni tűzfalamat dedikálni erre a feladatra, és bármely kliensről (laptop, asztali gép) bármikor használni a céges hálót - ilyenkor mi van? (bocs, ha nagyon buta a kérdés...)

a.

*: lehet USB kulcs, x509-es cert, ...

IPV6 esetében a tűzfalad mögötti kliens tartomány (ami egy /64 v /56 pl) ugyanúgy route-olt a világban mint a tűzfalad külső IPV6-os címe. Ennyi. Nincs nat,privát ip tartomány stb. a tűzfalad simán route-ol.

Magyaran a belso halon levo gepeimet is teljesen siman ellehet majd erni kivulrol, minden portot es szolgaltatast?
Szurni ezek szerint csak a hoston fogok tudni?

-------------------------------
“The 0 in Raid 0 stands for how many files you’re going to get back if something goes wrong” :)

Szűrni ugyanúgy tudsz a tűzfaladon. (szappantartódon, home gateway-eden vagy bárhogy is hívják.)

Ok, hulye kerdes volt, kozben rajottem.

-------------------------------
“The 0 in Raid 0 stands for how many files you’re going to get back if something goes wrong” :)

Hello,

bocs, nem igazán ez volt a kérdés: mi van, ha nekem _KELL_ a NAT? Ha mondjuk annyira penge lennék, hogy netfilterhez írnék modulokat, akkor sem tudnék NAT modult írni? Tehát a protokoll tervezéséből adódóan nem lehet NAT-olni?
(tehát a kérdés a "miért nincs NAT?")

Van privat cimtartomany:

fc00::/7 are the unique-local addresses [RFC4193]. Addresses within
this block should not appear by default on the public Internet.
Procedures for advertising these addresses are further described in

NAT meg innentol csak feature.

Az hogy kinek mikor mekkora prefixet adnak az nem hasrautes, a kovetkezo semat kene mindenkinek kovetni es akkor jut is marad is: http://www.ietf.org/rfc/rfc2374.txt

--
http://bsdbased.com

Van privat cimtartomany:
hmm, tehát a post-ban a fenti állítás (ráadásul NAT sincs) hamis? :)

Nem hamis az állítás. Lehetne NAT-ot csinálni (sőt vannak mindenféle érdekes kezdeményezések) ez programozási kérdés kizárólag. Nem ez a lényeg. Az IPV4-ben a NAT egy csúnya hack. Egy csomó dolog háklis rá: több csatornás protokollok, voip,stb ami miatt meg kell bonyolítani a csomagszűrőket, proxykat stb különféle helperekkel.

Ezt a hack-et senki nem akarja mégegyszer az IPV6-ban mert minek.

Ha azt szeretnéd, hogy ne a belső címtartományod látszódjon kifelé akkor proxy-t kell használni.

Van egy régi niif-es áttérés ipv6-ra leírása érdemes megnézni:

http://ipv6.niif.hu/tipster6/papers/overview/4.transitipv6.html

Hello,

a linket köszi, elkezdem nézegetni... :)

Tényleg nem nyelvészkedni akarok, csak megérteni dolgokat:
"ráadásul NAT sincs" - "Lehetne NAT-ot csinálni" => "Nem hamis az állítás."

??

tehát NAT van :)

a.

Megpróbálok a blogomba reszelni egy IPV6+Squid+Tproxy leírást amint lesz rá időm.

Addig is olvasnivaló:

http://wiki.squid-cache.org/Features/IPv6

Ne érts félre, csak óvatosan kérdem: ugye tudod hogy NAT != app proxy?

Természetesen tudom mi a különbség, de egy transzparens generic(plug) tcp vagy udp proxyval (hívd L4 proxynak ha akarod) el lehet érni a kívánt hatást meg még többet is a squid csak példa volt, bár L7 proxyra.

Proxy esetében két kapcsolatod van egyik a kliens és a proxy között a másik pedig a proxy és a szerver között. Namost meg lehet azt oldani, hogy a kliens által feladott kéréseket a proxy elfogja (transparent interception) és aztán a saját kliens oldali címével (vagy bármely beállított címmel) kérdezzen tovább. Tehát nem az van mint NAT esetében ,hogy egyszerűem a kimenő packetek a fejlécben kicserélem az ip címet.

De az belátható, hogy a te szempontodból mindkét esetben címfordítás történik. Szóval a proxy terminológiában is értelmezhető a NAT csak nem úgy.

Sebastian Krahmer (a.k.a. Stealth, aki mellesleg az egyetlen komoly haxor múlttal rendelkező fejlesztő az Enterprise Linux disztribúciót szállítók között ;) írt egy kis user-space daemon-t az év elején, ami IPV6 NAT-ot valósít meg. Elérhető itt.

NAT lehet, természetesen semmi sem akadályoz meg benne, hogy megcsináld. De azt jó eséllyel nem fogod megtalálni az IPv6-os otthoni routerekben, meg mintha talán a linuxos fejlesztők is elutasítanák a gondolatot.

Így kell érteni azt, hogy "nincs".

A linux fejlesztők a TPROXY-t erőltetik helyette,mert gányolás nélkül oldja meg a problémát. Igaz a TPROXY ipv6 támogatás még nincs a mainline-ban.

Rendben, hogy szinte végtelen sok ip cím lesz így, de minek kell /64-es prefixet kiosztani? Nem lenne elég egy /112 ?
--
"my mind had skipped town and left me behind to pay the rent"

/64 eseten az otthoni routeren is futhat egy radvd amivel plug and play modon megy a cimkiosztas minden otthoni eszkoznek. Ez csak ekkora prefixel megy
--
http://bsdbased.com

Ez a szabványban van meghatározva? A T-online egy /64-es tartományból az összes előfizetőjének tudna elegendő ip-t adni.
Így se futunk egy ideig a v6-os címekből, csak pocséklásnak tűnik.
--
"my mind had skipped town and left me behind to pay the rent"

Pocseklas csak a kisebb problema (amugy nemaz, lasd fenti postban az rfct). A nagyobb problema a Neighbour Discovery protokollkeszlet tamadhatosagan alapul, ami pl az ARP funkcioit is magabanhordozza. Akar egy darab csomag kuldesevel el lehet dobatni a linken tartozkodo osszes gep IPv6 cimet, szoval amig ezeket alacsonyabb szinteken nem szurik ugy, hogy mukodjon is meg biztonsagos is maradjon, addig nem fog tovabb terjedni a dolog. Valoszinu emiatt dontott ugy a T is hogy kulon legyen egyelore a jatszos ipv6.
--
http://bsdbased.com

Pontosan nem ismerem a Neighbour Discovery protokollkészlet mibenlétét, de az IPv4 ARP is van olyan anszikjúr, hogy minimális erőforrás bevetésével megbénítsd a vlan -od, szóval nem lehet komoly visszalépés. :)

A lényeg, hogy IPv4-en ezek kivédésére vannak megoldások, amelyek IPv6-ra még nem annyira hozzáférhetők.

azt hiszem erre feliratkoznék... sosem árt.

--
xterm

Valaki mesélje el ezt, mert nem értem.

subscribe, tudod :) hogy /trackben latszodjon utana.

Jó, az első részét értettem, csak azt nem, hogy mire jó. Tehát hozzászól, felkerül emiatt a "tartalmak követése" oldalra, és ott meg később is látszik, hogy ha volt hozzászólás.

Ah so, ez új volt.

Nem tudom, nekem az jobban tetszene, hogy azokból a cikkekből, amikhez hozzászóltam összegyűjtené egy helyre az új kommenteket, és ha azokat elolvastam, eltüntethetném, és megint csak az újabbak látszanának.
Netán erre is van megoldás? :)

+1

(Bra: ez is csak egyfajta subscribe ;-))

(Csak hogy értelmeset is írjak.) Még délután a cikk átfutása közben ránéztem a szappantartómra. Sajnálattal láttam, hogy ugyan van pár ilyen "pass-through" lehetőség, a PPPoE pass-through nem szerepelt közöttük. Noha biztos voltam benne, hogy kudarc lesz a vége, elkezdtem újabb frimware-t keresni. És lőn csoda, találtam egy idén nyáron készült verziót. Frissítettem. Abban se volt. Ezek után elkezdtem olvasni a T-rex-es doksikat, és legnagyobb meglepetésemre abban szerepel, hogy az enyim is tudja! Hihetetlen, de ebben az esetben egy kicsit több esélyem van a tesztelésre (ugye FreeBSD-sek gőzerővel dolgoznak azon, hogy működjön végre az ipv4-mentes rendszer).

ez mikor lesz, 9.0-release?


szerintem.

Érdekes és remek írás, grat!

> Sajnos az IPv6 egyik legnagyobb hátránya még mindig a kevés elérhető tartalom

Ez mit jelent? Mifele tartalom?

x(5-10) ev mulva, amikor mar az ISP-k tobbsege (80-99%a) az ugyfeleiknek IPv-6-ot nyujt, alkalomadtan visszaterhetek-e IPv4-re?

Mashogy fogalmazva, ha az OSI retegben gondolkodunk, csak akkor eri el az ugyfel es a kiszolgalo egymas 4. reteget, ha mindketto 3. retege egyforma, mindketto IPv4, vagy mindketto IPv6? Vagy ez nem feltetel?

Nyilván az, de vannak megoldások (IP szinten és felette is, pld. alkalmazás-proxyk), amelyekkel megvalósítható az átjárás.

Nem kotekedni akarok, csak mar tobb helyen olvastam ugyanezt, de sose
ertettem, es itt tettem fel a kerdest.

Mit jelent ez a mondat:
"Sajnos az IPv6 egyik legnagyobb hátránya még mindig a kevés elérhet# tartalom"

Ebbol a mondatbol azt nem ertem, hogy:
Mi az hogy keves a tartalom?
Miert hatrany ez?

Boncoljuk a mondatot:
Tartalom: a kiszolgalok nagy resze csak IPv4-es.
Kellenek utvalasztok, amelyek kettos labuak: IPv4-es es IPv6-os is egyben. Ezen keresztul lehet elerni a masik halozatot.
Ha az ugyfel all at elobb IPv6-ra es a kiszolgalo meg IPv4-es, akkor is kell.
Ha a kiszolgalo all at elobb IPv6-ra es az ugyfel meg IPv4-es, akkor is kell, bar ebben ez esetben a kiszolgalo
talan megtart egy IPv4-es feluletet is.
De ez nem tekintenem hatranynak, mert amig 100%-ig nem all at az egesz Internet IPv6-ra, addig amugy is lesznek
ilyenek, nem?

Akarhogy is megzavart ez a kijelentes, megiscsak ugy nez ki, hogy atjarhato egymas kozott a ket halozat.
"IP szinten és felette is, pld. alkalmazás-proxyk"
Pont ezert nem ertem a mondatot. Talan nagyobb a koltsege az atalakitasnak? Ez lenne a hatrany?

Szoval mit jelent ez a mondat?

A kérdéseid nagyban arról tanúskodnak, hogy fogalmad sincs arról, hogy működik az IPv6, IPv4 és ezek egymással hogyan korrelálnak.

Igen, ezert is koszonom szepen (tenyleg), hogy ennek ellenere kaptam valaszokat, es majd tanulok.

http://www.alexa.com/topsites
host facebook.com
facebook.com has address 69.63.187.17
facebook.com has address 69.63.187.19
facebook.com has address 69.63.181.11
facebook.com has address 69.63.181.12
facebook.com has address 69.63.184.142

host yahoo.com
yahoo.com has address 209.191.93.53
yahoo.com has address 69.147.114.224
yahoo.com has address 209.131.36.159

host live.com
live.com has address 207.46.30.34

host wikipedia.org
wikipedia.org has address 208.80.152.2

Ezt jelenti.

Az ISP-knek tulajdonképpen nem jelent kezelhetetlen problémát az IPv4 sem, ha kifogynak a címekből, majd NAT-olnak, a hálózati gyártók már elkészítették nekik a megoldásokat:
http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6553/white_paper_c11-558744-00_ns1017_Networking_Solutions_White_Paper.html

Talan nehez a felfogasom, de erre a kerdesre meg mindig nem tudom a valaszt (felteszem negyedjere is):
IPv6-os cimrol nem lehet elerni az IPv4-es cimeket?

Nem, nem lehet.

lehet azt becsülni, hogy mikortól működhet majd tisztán ipv6-on egy rendszer, v4 nélkül?

Akár már ma is, ha az alkalmazások támogatják, és nem feltétel, hogy v4-es hostok is elérjék. :)

Subscribe, és grat, szép írás :)
--
Discover It - Have a lot of fun!

+1

-------------------------
E-learning szolgáltatások nyílt alapokon
Weblap és Bemutató rendszer

+1

Köszi a szép írást, de eszembe ötlött egy probléma: "A doksiból kiderül, hogy a /64-es címek osztása ún. "kvázi fix" módon történik".

Namost, nekem otthon a cuccaim dhcp-vel kapnak címet, egy belső tartományból, ahogy ez az ipv4-nél megszokott dolog. Gondolom ipv6 felett úgy kellene, hogy abból a /64-es tartományból kellene osztanom, amit kapok, mert ugye. Értem én, hogy ez nem nagyon fog változni, és ahogy néztem, az ipv6-os dhcp kliensnek van egy "script" sora, amivel lehet varázsolni, de akkor is, ha jól sejtem az probléma, hogy egyszer egy bizonyos /64-es tartományt kapok, és nem tudom, hogy mikor fogok másikat kapni, amikor is a belső hálózatomban lévő gépeknek hipp-hopp szintén címet kellene váltaniuk (ami egész érdekes fényt vet az esetleges dinamikus reverse dns megvalósításra)

Egyelőre az se biztos, hogy tudok otthon ipv6-ot kapni, nincs kedvem távolról kipróbálni, de most nagy kedvet kaptam hozzá :)

Amugy szerintem bra ugy ertette, hogy felcsatlakozaskor egy /64es prefixbol kapsz egy cimet, nem pedig egy prefixet. Tehat minden usernek ugyanazzal fog kezdodni a vegpont cime. Erre a vegpont cimre routeolnak egy kulonallo /64 tartomanyt, amire pelda nincs a cikkben. Erdekes lesz megoldani mindenesetre ennek automatizalasat. Valoszinu szerzodeskoteskor hozzadrendelnek egy fix tartomanyt amit a jovo otthoni routerebe majd bepotyogsz hogy azt hirdesd a belso labakon.

Minel tobbet agyalok ezen a teman annal tavolibbnak latom az otthoni ipv6ot. A specifikacio szerint routeren nem szabad hogy mukodjon a statless addr. autoconf, es valoban linuxnal ipv6 forwarding eseten nem huz fel router hirdetesre cimet, es ha utolag kapcsolod be a forwardingot akkor pedig eldobja a defaultroute-ot.

Szerintem az otthoni routerekre kene radiuskliens, az pedig a delegalo routeren keresztul kerne egy prefixet maganak, szerencsere erre is van mar rfc, szoval mar csak ido kerdese es osszeall a kep.
http://www.ietf.org/rfc/rfc4818.txt

--
http://bsdbased.com

jaja, megkavarodtam a 64-56 sok szám között :)

Nekem amúgy azért kellene otthonra az ipv6, hogy tudjam próbálgatni. Meg kell ismerni, mert ha pár év múlva tényleg ipv6 fog folyni a csapból is, akkor már nem árt felkészültebben állni :D

Nem, prefixet kapsz, a szolgáltató AAA rendszere nem is tudja, hogy mi lett aztán az IP-d azon belül.
Nézd meg a Varga Balázs féle anyagot (16. oldal), ott le van írva folyamatában is.

Nem, a /64-et nem oszthatod tovább. Arra az a /56 szolgál, amit DHCP-n elkérhetsz.

na bocs de akkor en szandekosan olvastam felre, mert nemhittem el amit latok. csak igy fel nem tudom fogni miert kell /56 egy haztartasba. Az RG-nek meg kulon /64.
--
http://bsdbased.com

A /64 azért kell, hogy a routerben valamire routeolni lehessen a /56-ot.

Miert kell ket lepesben megkapni a /56 -t ?
"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."
Ez akkor is igaz, ha elkeri /56 -ot ?
Miert nem /48 ?


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Teljesen felesleges lenne minden usernek odacsapni egy /56-ot, ha amúgy nem használja. A két lépésre az előadásban (de a cikkemben is) megtalálod a választ, a cickó routerekkel egyelőre csak így tudták megoldani az összerendelést.

Akkor is igaz. Mire nem elég egy /56? Egy nagyvállalat is 99%-ban bőven belefér 256 subnetbe.

Mindenre eleg :)
Elvileg minden ipv4 cimhez "ingyen" jar egy /48. Szolgaltato ezt minden tovabbi nelkul kioszthatna.
Nem tudom menyire szerencses dolog ugy 6to4 -ezni, hogy nem /48 ad van, ill. masnak is van cime a neked jaro /48 ban.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Tartalmas, stílusos. Köszi, bra!

Egy gyakorlati kérdés:

Adatparkban hostingolt szerverre hogyért/mennyiért/hogyan lehet IPv6 címet kérni?

--
The reason that half of us are in computing at all is that we see computers as things that we can make beautiful things out of..

Ld. fentebb: egyelőre sehogy.

Remek írás.
Lehet piszok hosszúak, de legalább jól rövidíthetőek, már amelyik.
Az utolsó 64bitből meg geek-sms lesz, már látom. :)

Es miert olyan nagy hatrany, hogy keves kiszolgalo tett az IPv6 fele lepeseket, hiszen ezek IPv6-rol is elerhetoek.
Talan halozati szempontbol koltsegesebb, alkatreszek szempontjabol nagyobb eroforrasokat igenyel az atjaras?

Hm, miért gond az, hogy a szolgáltató rádkényszerít egy olyan technológiát, aminek _tényleg_ meg vannak számlálva a napjai?

Ugy erti, hogy:
miért gond az, hogy a szolgáltató rákényszerít, hogy valts egy olyan technológiárol, aminek _tényleg_ meg vannak számlálva a napjai?

En ugy ertettem, mintha az IPv6 terjedesenek egyik hatraltatoja ("legnagyobb hatrany") az lenne, hogy a kiszolgalok nem valtanak IPv6-os feluletre.
Pedig ha nem valtanak, akkor is elerhetoek IPv4-es feluleten egy IPv6-os ugyfelrol.

Míg nem terjed el az ipv6, addig nem váltanak ipv4-ről. De amíg nem váltanak ipv4-ről, addig nem terjed el az ipv6. Valakinek lépni kell.

Részemről az általam üzemeltetett gépeknél, hálózatoknál fel akarom húzni az ipv6-ot is, de most úgy tűnik, hogy itthon kis se tudom próbálni, mert a chello nem ad ipv6-ot. De hétfőn kiderül, akkor tudom őket felhvíni.

Tunnel broker neked erre az esetre nem megfelelő alternatíva?

Tévedésed jelen esetben ott leledzik, hogy egy v4-only szerver csak akkor érhető el egy v6-os kliensről, ha az a v6-os kliens egyben v4-es _is_. Magyarán ipv4-et is tud minden további nélkül.

Évekkel ezelőtt axelerós dialuppal kaptam v6-os címet, és akkor tesztfázisban lévő kollégiumi szerverekhez tudtam csatlakozni...
Pontos időpontot nem tudok, de az egyetemek kb. ekkor kezdtek el v6-os címekkel operálni, rögtön ki is próbáltuk.

--
deejayy DOT hu

bra teszt idoszak elmeletileg lejart, mi varhato most? Adatpark/dataplex ben mikor lesz elerheto?