IPv6 topic

IPv6

szerk* : "9999 comment nézet" - innen
szerk2*: 2. oldal

Csak egy kezdeményezés, hogy legyen egy "community" hely a -tiszta- kérdéseknek, és válaszoknak IPv6-al kapcsolatban, avagy "szálljon fel a köd".

Kezdem egy pár ""alap"" kérdéssel - netről kikerestem a válaszokat [ergo FIXME]:

Q: IPv6 alatt mi lesz a localhost címe?
A: ::1

Q: Hogyan néz ki egy IPv6-os cím?
A: Egy IPv6-os cím 8 db 4 hexadecimális számjegyből álló csoportból áll, kettőspontokkal elválasztva. Egy érvényes cím a következőképp nézhet ki: 2001:0db8:85a3:08d3:1319:8a2e:0370:7334

Q: "Rövidíthetőek" valahogy ezek a hosszú címek?
A: Négy 0-ból álló négyes (0000) elhagyható, és helyére négyespont írható (::). Így több 0000-s négyes is átírható négyespontokká, illetve a négyesekből a vezető nullások is elhagyhatóak (pl.: 0d56 → d56)
Ilyen módszerrel viszont csak egy ilyen nullásokból álló csoport hagyható el, több nem, azaz például:
2001:0db8:0000:0000:34d2:0000:1428:57ab
nem helyettesíthető
2001:0db8::34d2::1428:57ab
-vel, hanem a helyes rövidítés:
2001:0db8::34d2:0000:1428:57ab
2001:0db8:0000:0000:34d2::1428:57ab

Q: URL-ként írhatok be IPv6-os címet?
A: Igen, de az URL címben szögletes zárójelek közé kerül az IPv6-os cím, pl.: http://[2001:0db8:85a3:08d3:1319:8a2e:0370:7344]/
És a portot kettősponttal elválasztva tesszük hozzá: http://[2001:0db8:85a3:08d3:1319:8a2e:0370:7344]:443/

Q: Vannak speciális, elkülönített címek az IPv6-ban?
A: Például:
::/128 – csupa 0-ból áll, nem kiosztható
::1/128 – localhost cím
::/96 – IPv4 kompatibilis címekre használták, már elévült
::ffff:0:0/96 – átfordított (mapped) IPv4-es címekre
2001:db8::/32 – dokumentációkban és IPv6 leírásokban használt cím
fe80::/64 – analóg az IPv4-es 169.254.x.x autokonfigurációs címmel
ff00::/8 – multicast prefix a multicast címekhez

Q: IPv6-os címet használok már?
A: Itt megnézheted: http://www.sixxs.net/tools/ipv6calc/

Q: IPv4 esetén a "minimum Maximum Transmission Unit" 68 Byte [FIXed!], IPv6 esetén van valami változás esetleg?
A: IPv6 esetén a "minimum Maximum Transmission Unit" értéke 1280 Byte
Az IPv4, és IPv6 maximum datagram [FIXed!] mérete 64 KByte lehet.

Q: IPv4 esetén a forrás, vagy a router "eszköz" darabolhatta a csomagokat [fragment the datagrams]. IPv6 esetén?
A: IPv6 esetén csak a forrás eszköz fragmentálhatja a csomagokat. A routerek nem.
Tehát a küldés előtt "ki kell egyezniük", mi legyen a közös MTU.
IPv6-nál a fragmentek összerakása, úgy mint IPv4 esetén a cél eszköznél történik.

Q: Tiltsam az ICMP-t IPv6-on?
A: IPv6-on Főleg NE tiltsd az ICMP-t, mivel azzal "megölöd" a hálózatot - neighbor discovery, router discovery, PMTU.
IPv4 alatt Sem ajánlott tiltani az ICMP-t, legalább a hibakeresés miatt. [Egy érdekes "hibajelenség": vajon miért csak a kis méretű weboldalak/e-mailek töltődnek be, a nagyobb fájlok pedig nem??? - Azért, mert nem tudtak megegyezni egy helyes MTU-ban az ICMP tiltása miatt.]

Ha lehet kérni az szóljon hozzá, akinek:
- BÁRMI kérdése van az IPv6-al kapcsolatban, valaki csak tudja rá a választ [akár Google-ből adott :)]
- FIXME-re van ötlete, javítása
- tudja a választ
- "tudja egy idáig fel nem tett kérdésre a választ", és azt esetleg leírja, hogy az ne legyen később kérdés

Előre is Köszönöm azoknak, akik jártasak az IPv6-ban, és esetleg válaszolnak az itt feltett kérdésekre.
Azoknak is köszönet, akik itt teszik fel a témába vágó kérdéseiket.

ui.: egy blogbejegyzés erről

( lcsaszar v | 2009. 06. 01., h – 22:15 )

IPv4 esetén a minimum MTU 68 Byte, IPv6 esetén a minimum MTU értéke 1280 Byte.

A legnagyobb datagram méret mind IPv4-nél, mind IPv6-nál 64 kByte, ezt a csomag fejlécének "payload length" mezője határozza meg. Ezzel szemben a maximális MTU-t mindig a média határozza meg, pl. Ethernet 1500 byte, jumbo 9000 byte. Az MTU-ból levonva a fejléceket (pl. tipikusan 20 byte TCP és 20 byte IP) kijön a Maximum Segment Size (MSS) azaz a fragmentálás nélkül átküldhető legnagyobb datagram méret.

Az 576 byte MTU onnan jön, hogy IPv4 esetén 536 byte az a legkisebb datagram méret, amit minden host-nak tudni kell kezelni feldarabolás nélkül. Datagram az az adatcsomag, amit az alkalmazás át akar küldeni IP-n, ez kap TCP és IP fejlécet (együttesen 40 byte), így jön ki az 576 byte MTU. Ezt akkor használják, ha a küldő és a fogadó nem tud megegyezni nagyobb MSS-ben, mert így biztos, hogy a csomag a továbbitás során nem lesz feldarabolva. IPv6 esetén az így kiadódó MTU 1500 byte, vagyis ennél kisebb csomagot soha nem darabol fel az IPv6 router.

( Mik v | 2009. 06. 09., k – 08:30 )

Az autoconfig meg tudja tréfálni az embert. Nálunk a tűzfal csak a kézzel kiosztott (én osztom ki) címeket engedi át. A Linuxok egy része (mind?) viszont hajlamos az autoconfig címmel dolgozni akkor is ha van kézzel beállított cím. Megoldás:
/proc/sys/net/ipv6/conf/eth0/autoconf érték 0-ra állítása.

Mik

( LGee | 2009. 06. 09., k – 12:43 )

Javaslom, hogy told fel a wikibe is, hogy konnyebb legyen hozzanyulnunk.

( LGee | 2009. 06. 09., k – 12:59 )

Q: Milyen OS nem tamogatja az IPv6-ot?
A: Windows 2000 es korabbi verziok, Linux kernel 2.6.x elotti verziok, AIX 5.2 elotti verziok... [FIXME]

Lasd meg:
IPv6 in Operating Systems
IPv6 – Ready for Prime Time? Part IV: Vendor Support - April 18, 2007

Q: Milyen proprietary hardver nem tamogatja az IPv6-ot?
A: Bizonyos SOHO routerek, kabelmodemek, SIP telefonok es nyomtatok.

Q: Hogyan tilthatom le az IPv6-ot a kulonbozo operacios rendszerekben?
A: Vagy valami kernelparameterrel (sysctl), vagy a firewall segitsegevel. [FIXME]

( honorshark | 2009. 09. 19., szo – 08:43 )

Koszi a leirast. Nemreg UPC valtott ipv6-ra, de linux alatt (Ubuntu) az istenert sem sikerult beuzemelni a netet.

Komolyan. Az uj szolgaltatasai (mint a fibernet vagy mi a neve..szoval ami optikaival jon), az mar ipv6-ot oszt. Nemtudtam egyszeruen linux alatt beallitani. De most komolyan..hogyan kell? #ubuntu-n se tudtak segiteni (Ubuntu-s az illeto akinek bekotottek), se mas IRC csatornakon nem kaptam valaszt.

Ubuntu wiki-t is felturtam, de semmi. Neten talaltam forumtopicot hogy valami dhcp v6 -os csomag kell, felraktam, probaltam, de semmi ip-t nem kapok. Fura. VMware alatt probalkoztam (nekem nincs ilyen netem, csak a delikvensnek), nekem poccre ment.

UPC hálózatból:
C:\>ping ipv6.google.com

ipv6.l.google.com [2001:4860:a003::68] pingelése - - kiindulópont: 2002:5985:2990:satöbbi 32 bájtnyi adattal:
Válasz 2001:4860:a003::68: idő=343 ms
Válasz 2001:4860:a003::68: idő=56 ms
Válasz 2001:4860:a003::68: idő=57 ms
Válasz 2001:4860:a003::68: idő=58 ms

2001:4860:a003::68 ping-statisztikája:
Csomagok: küldött = 4, fogadott = 4, elveszett = 0
(0% veszteség),
Oda-vissza út ideje közelítőlegesen, milliszekundumban:
minimum = 56ms, maximum = 343ms, átlag = 128ms

C:\>tracert ipv6.google.com

Útvonal követése a következőhöz: ipv6.l.google.com [2001:4860:a003::68]
legfeljebb 30 ugrással:

1 * * * A kérésre nem érkezett válasz a határidőn belül.

2 42 ms * * swiFR2.switch.ch [2001:620:0:c000::17]
3 45 ms 43 ms 44 ms swiBE2-G2-5.switch.ch [2001:620:0:c025::2]
4 43 ms 44 ms 44 ms swiBE1-10GE-1-4.switch.ch [2001:620:0:c035::1]
5 43 ms 47 ms 44 ms swiLS2-10GE-1-1.switch.ch [2001:620:0:c03c::1]
6 60 ms 44 ms 44 ms swiEL2-10GE-1-2.switch.ch [2001:620:0:c00c::1]
7 44 ms 44 ms 44 ms swiCE3-10GE-1-3.switch.ch [2001:620:0:c06a::1]
8 60 ms 60 ms 61 ms pr61.ams04.net.google.com [2001:7f8:1::a501:5169
:1]
9 * * * A kérésre nem érkezett válasz a határidőn belül.

10 * * * A kérésre nem érkezett válasz a határidőn belül.

11 126 ms 66 ms 57 ms fx-in-x68.google.com [2001:4860:a003::68]

Az útvonalkövetés elkészült.

Igazad van. Nincs. :)
Úgy tűnik, hogy azt azzal az anycast címmel senki sem törődik.

A Miredo alapból erre kapcsolódik: teredo-debian.remlab.net
(Ez van az /etc/miredo.conf-ban)
(Kiszámoltam a kapott ipv6 címből és tényleg erre kapcsolódik)

A Windows pedig elvileg erre: teredo.ipv6.microsoft.com
(Wikipedia szerint...)

Ezek szerint úgy látszik, hogy ennek az egésznek semmi köze a UPC-hez... Annak, hogy a Teredo működjön annyi a feltétele, hogy legyen egy publikus ip címed és ne szimmetrikus NAT mögött legyél.

Isten ments! Viszont minden netelőfizető nagyon sok ipv6 címet kap (egy hatalmas blokkot), ergo nincs szükség NAT-ra.
Rémálom bármilyen p2p szoftvert írni a NAT-ok miatt. (Nem véletlen, hogy pl MSN-en gyakran nem működik a audió/videó. Nem véletlen, hogy Pistikének a Create Lobby gomb megnyomása után nem tudnak beszállni a barátai. etc...)

Lehet-e? Nem. Lásd: http://hup.hu/node/39002

alapbol a ping6 nem allitja be a don't fragment bitet szoval a ping6 -s 20000 majd elkuldi neked (20000+(ICMP+IPv6header))/MTU darab csomagban szoval az nem mond el semmit. Valoszinu, hogy MTU mismatch van feljebb. Probald meg lejebb venni az MTU-dat. Nem tudom, hogy mi a standard MTU v6-nal de a minimum az 12xx, es ha linux van eleg ertelemes akkor megmondja neked, hogy v6 alatt mi az a minimum.

1. nemcsak a pinggel van baj, semmi nem megy kb, ami egy packetnél nagyobb, ezért néztem ping -s 20000-ret. ssh belépés még ok, de egy top vagy mc halál. Web sem megy, kérés még elmegy, aztán várakozás végtelensésig. FTP belépés megy, dirlist (kis könyvtár) megy, le/feltöltés die.
2. próbáltam már játszani az mtu-val, bár a tracepath6-ot nem ismertem, kézzel golyóztam ki a minimumot, de azzal sem ment, és a minimum és max között próbált pár random értékkel sem.
--
Discover It - Have a lot of fun!

Erről tudsz valami információt mutatni? Engem konkrétan az érdekelne, hogy az összes csomagnál elérhető-e Nagykanizsán az IPv6?

Egyébként - lehet hülye kérdés lesz - az IPv6-hoz használható a régi modemük is, amit úgy 2 évvel ezelőtt kaptunk, vagy kell kérni másikat?

( xbit | 2009. 10. 02., p – 08:26 )

Hali!

Valamelyik nap ipv6 on probalkoztam sshzni, pingelni, a helyi halozaton. az volt a furi, hogy a cim melle mindig interfacet is meg kelett adni, kulonben a rendszer nem tudta vegrehalytani a feladatot. pl ping6 siman nem megy csak ping6 -I ethx kent, ssh a cimet csak ebben a formaban ertelmezi:
[cim]%ethx
Miert nem routeol, mint ipv4 nel?
ez altalanos, hogy interface el teljes egy ipv6 cim?(ha esetleg mondjuk a bongeszok ezt el is tuntetik)?
Vagy hogy is van ez az egesz?

koszi,
zsolt

Az fe80:0000:0000:0000::/64 automatikusan kiosztott
cím. Nekem minden hálókártyámon ebből a tartományból szereplő cím van. Így nem lehet meghatározni, hogy melyiken menjen ki a forgalom.
üdv.
nagysa

nagysa:~# route -A inet6 -n
Kernel IPv6 routing table
Destination Next Hop Flag Met Ref Use If
fe80::/64 :: U 256 0 0 eth0
fe80::/64 :: U 256 0 0 tap0
::/0 :: !n -1 1 17 lo
::1/128 :: Un 0 3 67 lo
fe80::21c:c0ff:fe92:8f7c/128 :: Un 0 1 0 lo
fe80::2ff:aeff:fe46:1799/128 :: Un 0 1 0 lo
ff00::/8 :: U 256 0 0 eth0
ff00::/8 :: U 256 0 0 tap0
::/0

Áááá...
Most nézem ezt még elemeznem kell!!!

Az fe80::/64 -es címek a link-local addressek ip6-on, mint ahogy azt az ifconfig is mutatja, SCOPE=LOCAL.
otthoni használatra javasolni tudom public ip esetén vagy a 6to4-et, (2002-es prefix) vagy egy tunnelbroker (2001-es prefix ;) használatát, mint pl tunnelbroker.net, vagy akár nat mögül a sixxs.net aiccu progija is tökéletes.
--
I feel the power!

( vtechun | 2009. 10. 03., szo – 19:00 )

Sziasztok!

Ha DSL-el felcsatlakoztam ipv6-al, megy is pl a hup.hu is, meg ipv6-os oldalak, de sima ipv4-es ip cimmel rendelkező oldalak nem jonnek be, ez normális ?

Fél év eltelt 2010-ből és semmi. Pedig még a routerem tomato firmware-jéről is átállnék openwrt-re (előbbiben nincs ipv6 support). A kérdés csak az, hogy milyen módon lehet egy ISP-nél (konkrétan Invitel) _a_ kompetens személlyel beszélni ezügyben.

---
> man woman
No manual entry for woman

( gbor | 2009. 10. 10., szo – 20:43 )

tök mindegy, hogy 2011 végén fogy el az összes kiosztható ipv4 cím, vagy 2012-ben, lényeg hogy agyilag elgondolkodik az ember, ipv4 címből már a cisco emberei mondják hogy nincs sok, nem igazán lehet valószínűsíteni, hogy a cisco-nál kezdők dolgoznak....csak gondoltam figyelni kéne, legalább egy kicsit az ilyenre, és nem hátra tett kézzel lehurrogni a másikat, hogy persze-persze-persze...

ha fizikailag elfogynak a címek, akkor nincs mit tenni, natolva lesz a natolt háló, aztán az is natolva lesz, és akkor találja ki a jézuska [vagy egy ip-t több eszköz használ? mobilnet-vodafone-2009?], hogy honnan jött a gonosz krampusz, vagy mi? ipv6 pár éven belül biztosan ismert lesz a legkisebb informatikus szemében is, terjednie kéne már nagyonh, vagy valamih, mert tökre poénosak lesznek a "véletlenek" miatti netkiesések:( mármint csak valószínűsítek

topic-ot azért indítottam, mert én sem vagyok még teljesen tisztában az ipv6-al, nincs sok szabadidőm:S

Hülyeség, pont a Cisco nem sokat tett az elmúlt jópár évben azért, hogy az IPv6 terjedjen. Még ma is teljesen alapvető dolgok hiányoznak, amik IPv4-en működnek, IPv6-on pedig nem...
Az utolsó pillanatra hagyták ezt is.

suckIT szopás minden nap! Lefoglalták a warezt hostoló routereket, megállt a magyar internet

Igen, sajnos az a gond, hogy hiaba igyekeznenek a routergyartok atallni ipv6-ra, ha egyszeruen a nagyobb szolgaltatok nem allnak at. MSN, Skype, a nagyobb VoIP szolgaltatok meg mind-mind ipv4 felett szolgaltatnak. Nem tudom, hogy akarnak itt atallast csinalni ketto-negy ev mulva, ha az ipv6 elterjedtsege meg mindig a banyabeka feneke alatt tanyazik. Elso korben olyan ISP-k kellenenek, akik csak ipv6 cimet adnak az ugyfeleiknek, ipv4-et egyaltalan nem, viszont biztositjak szamukra az ipv4 alapu rendszerek transzparens elerhetoseget (maga az ipv6 asszem tamogatja reszben ezt a reszet). Aztan lehet elgondolkodni azon, hogy hogyan tovabb.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( GergA84 v | 2009. 10. 26., h – 12:11 )

Üdv!

Egy kis segítségért fordulnék a HUP felhasználóihoz.

Van egy IPv4 cím amit manuálisan át kell váltani IPv6-ra. Először megnézettem egy online kalkulátorral ami a következőt mondta:
IPv4 cím: 80.98.95.100
Ipv6 cím: 2002:0:0:0:0:0:5062:5f64 (forrás: http://www.subnetonline.com/pages/subnet-calculators/ipv4-to-ipv6-conve…)
IPv6 cím: 2002:5062:5F64::(Forrás: http://www.kt2t.org/ipv4toipv6.htm)

Hexadecimálisba a 80->50, 98->62, 95->5F, 100->64

A kettő közül valamelyik nem lehet jó, valamint nem értem miéert kezdődik 2002-vel az IP cím.

RFC 2373 szerint (2.5.4-es pont)
2.5.4 IPv6 Addresses with Embedded IPv4 Addresses

The IPv6 transition mechanisms [TRAN] include a technique for hosts
and routers to dynamically tunnel IPv6 packets over IPv4 routing
infrastructure. IPv6 nodes that utilize this technique are assigned
special IPv6 unicast addresses that carry an IPv4 address in the low-
order 32-bits. This type of address is termed an "IPv4-compatible
IPv6 address" and has the format:

| 80 bits | 16 | 32 bits |
+--------------------------------------+--------------------------+
|0000..............................0000|0000| IPv4 address |
+--------------------------------------+----+---------------------+

Mi lenne az átszámolás menete?

Előre is köszönöm a segítséget.

-----------------------------------
http://virtualize.hu - Mert a virtualizáció a jövő :D

Azert kezdodik 2002 vel mert a 6to4 cimeknek a 2002::/16 tartomany van fentartva abbol kapja mindenki a cimeket.
tehat 2002:XXYY:ZZUU::/48 persze hexaban ahogy te is irtad egy x.y.z.u v4 cim eseten.

IPv6 address : 2002:5062:5F64::/48
Long version : 2002:5062:5f64:0:0:0:0:0
Range from : 2002:5062:5f64:0000:0000:0000:0000:0000
to : 2002:5062:5f64:ffff:ffff:ffff:ffff:ffff

Mondjuk én ip-t írok, így tőlem a dns állhat is, bemegyek ssh-val.

Érdekes, hogy azért, mert szélesebb a cím, miért nem maradhatott a régi formátumban, azaz decimális számokkal leírva a bíte-okat ? sokakat megzavar a hexadecimális forma és a trükközés a 00-ákkal...Miért nem jó, ha így írom le: 211.211.211.211.211.211/48 ? Így fájdalommentesebb lenne az átmenet. ...és ha már váétunk ipv4-ről ipv6-ra miért nem vesszük észre, hogy a hálózatok világa ma éli azt a forradalmi korát, amit az informatika a 80-as és 90-es években élt át és miért nem lehet mondjuk ipv10-re lépni ? Most fognak divatba jönni a hálózatba köthető háztartási gépektől kezdve minden bisz-basz, ami kommunikál, ha kell, ha nem. Ma egy otthonban van egy-két pc/laptop, pár éven belül lesz egy csomó kütyü, ami hálózatba lesz kötve, mondjuk egy otthonban 20-30...szerintem én még látni fogom, amikor az ipv6 címek elfogynak...és akkor gondolom majd áttérnek az ipv10-re de azt majd oktálisan kell leírni...mert csak.

De, megértem. Az ipv4 címtartománya nem elég a világnak ha 1 db ip/főben gondolkodunk....és akkor az egyéb címigényekről nem beszéltünk. Értem, hogy több nagyságrenddel nagyobb mennyiséget tud kiszolgálni...de ahogy valaha nem gondolták, hogy a 4294967296 elméletileg lehetséges ip cím kevés lesz, úgy ma sem látjuk előre, mit hoz a jövő és mint említettem, szerintem a hálózatos alkalmazások robbanásszerű fejlődése kezdődött meg. Ha belegondolsz, csak a szűk környezetedben ezer olyan dolog van, amit lehetne hálózaton vezérelni, lekérdezni, összekötni mással, hogy összehangold a kényelmed érdekében vagy éppen adatot gyűjthetsz, hogy tervezhessed a jövőt. Szóval annó ugyanúgy elájultak a négy byteos címtől, mint te most a hat byteos címtől ...és ma attól ájuldozunk, hogy jé de kevés...pedig még csak internetező tömegeket kell jellemzően(!) kiszolgálni, egyebekről még nincs szó. Tehát nem tudhatjuk - csak ájuldozhatunk a nagyságától - hogy 340282366920938463463374607431768211456 elméletileg lehetséges IP cím meddig és mire elég.

Másik példa: Emlékszel-e, hogy 15-17 évvel ezelőtt valahol egy bill gates nevű ember azt nyilatkozta, hogy a számítógépek memóriájának már nem kell fejlődnie, mert 640 kbyte mindenre elég ? másfél évtized eltelt és a windows 2 gb ram alatt kínlódás és nem eszköz, egy webszerverbe beletolnak 8-48 gb-ot ...és még mindig szűk keresztmetszet a ram...a diskek is jó páldák. Annó egy 20 mb-os diszken elfért a fél világ, ma meg egy 1 tb-os diszk otthon csak egy kis része a filmgyűjteménynek...

Összegezve: óvatosan a "megnézem én..." kezdetű mondatokkal. ;)

állítólag 10^25 homokszem van a szaharában, a megfigyelhető univerzum atomszáma pedig 10^80, hogy egy kicsit érzékeltessem. szóval az első állításoddal, miszerint megérted, hogy hány nagyságrenddel több szám áll rendelkezésre, mint amit valaha elhasználnánk, továbbra is vitatkoznék.

a kapacitással meg fölösleges dobálózni, mivel az kvázi végtelen korlátú, de maga a tároló mérete ugyanakkora marad, ha nem kisebb lesz. végtelen db elektronikai eszköz meg valszeg nem lesz a földön, nem tud exponenciálisan nőni, mert fizikai dolog, és nincs annyi nyersanyag a földön, hogy annyi szutykot legyárts, hogy kérhessen ip címet, még akkor se, ha 1cm^3 helyet foglal darabja. ezen kár vergődni.

legyünk nagyon-nagyon pesszimisták, és mondjuk, hogy 200 év múlva nem lesz elég, ami nagyon irreális. akkor 200 évig fog minket kiszolgálni az ipv6 címekkel. az ipv4 30 évig volt elég, úgyhogy még akkor is igen jó teljesítmény. de szvsz hamarabb írják át teljesen új alapokon az egész internetet, mint hogy az ipv6 címek elfogynának, úgyhogy csak azért, hogy te nyugodtan aludj, nem látom értelmét több sávszél elpazarlásának a címzés miatt.
szerintem.

Oké, revidiálom ezt a részt. Azt továbbra sem értem, miért kellett a címek felírásának a módját megváltoztatni és állítom, hogy ez az egyik nagy kerékkötője az áttérésnek.

Ami az ipv4 30 évét illeti, az biza jó ha 8-10 év. Ennyi idő alatt futott fel kritikusan az igény.

Az én megértésemről ne vitatkozzunk szerintem, tudom, hogy okos vagy, de engem a dolog farokméret része nem érdekel, mert ezen a téren én meg nyugodt vagyok és ezt empírikus úton szerzett tapasztalataimnak köszönhetem. ;)

jajó. tehát már tapasztaltad 10^38 cím elfogyását, zsír :)

azt aláírom, hogy a hexa talán nem a legideálisabb, de lehet úgy voltak vele, hogy emberileg úgyse megjegyezhetőek, mert túl hosszúak hozzá, akkor meg legalább rövidítsünk rajta egy kicsit, vagy a franc tudja.
szerintem.

Nem kevés alkalmazásban lehet ezt használni:
1.1.1
Ami 1.1.1.bármit jelent. Ha az IPv6 is ezt a formát használná, az alkalmazás nem tudná eldönteni, hogy v4, vagy v6-ról van szó.
Érdekes lenne ez is: 1.1.1..1

Nem hiszem, hogy ez túl nagy "kerékkötő" lenne, az IPv4-et is ugyanúgy meg kellett tanulnia annak, aki használja...

suckIT szopás minden nap! 2010 az IPv6 éve lesz

( PunishR v | 2009. 11. 13., p – 10:16 )

hasznalta mar valaki ipv6hoz a bind $generate funkciojat rev es rendes zonahoz?

( bambano | 2009. 11. 13., p – 18:57 )

lehet már ipv6-os internetet venni nagy szolgáltatóktól?

( xc0m v | 2009. 11. 28., szo – 11:59 )

Az lenne a kérdésem, hogy a jövőben az ipv6 címek miatt, mellőzhetjük a NATot és port-forwardot? Tehát, ha lesz egy ADSL kapcsolatom, de itthon 3 gép van mindegyik kap rendes online ip-t?

Nem lesz, van. Akik most DSL-en adnak IPv6-ot alapból egy /64-et vágnak rád, és kérhetsz mellé egy /56-ot, amit úgy osztasz, ahogy akarsz (pld. 256 darab VLAN-ba oszthatsz /64-et a routered mögött, azaz kb. 4722366482869 milliárd hostnak adhatsz publikus, internetről elérhető IP címet a router után).

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

A port forward ugye arra is hasznalhato, hogy van kifele egy gepem, amire dns mutat, es ezen mittudomen a 80-as portot valami webszerverre iranyitom, a irc portot a chat-ert felelos szerverre, etc. Igy a usernek csak a mittudomain.com -ot kell beirkalni mindenhova, es mindent eler transzparensen. Arrol nem beszelve, hogy load balancing eseten nem feltetlen a best solution a dns round-robin.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( xc0m v | 2010. 03. 24., sze – 19:32 )

Én azt nem értem, hogy ha bejön az IPv6 akkor a routerekre nem is lesz szükség? Tehát lakásban például elegendő lesz egy switch és minden rákötött eszköz kap netes ip-t?

Nem így lesz. Ugyanúgy szükség lesz residential gateway/home gateway-re, csak éppen nem fog natolni, hanem csak routolni. A szolgáltatódtól fogsz kapni egy /64-et vagy /56-ot és az RG ezt fogja hirdetni a belső hálózatodnak.

Ezt a linkkel érdemes lehet kezdeni az IPV6-al való ismerkedést: http://hu.wikipedia.org/wiki/IPv6

Olvasgattam a Wikit meg egy T-online-os cikket is, nagyjából értem az előnyeit, csak erre nem tértek ki, hogy most a mai eszközök akkor dobandóak lesznek vagy ugyanúgy képesek lesznek megosztani a Net-et.
Ha olyan wifi-s routert szeretnék venni, ami fel van készítve az IPv6-ra akkor tudtok ajánlani? Vagy ezek jelenleg még aranyárban vannak?

A Cisco Networkers-en most Januárban pont azon ment a problémázás, hogy jelenleg senki nincs a piacon IPv6 képes SOHO Home Gateway-el. Ehhez az is hozzájárul szvsz, hogy nem tisztult még sajnos az összes technológia kezdve a stateless vs stateful címzéssel a dns-el stb.

A piaci viszonyok miatt valószínűleg új eszközt kell majd venni, pedig a meglévő eszközök zöme egy firmware frissítéssel iPv6 képessé tehető.

Nem hinném, hogy ezek sokkal drágábbak lesznek egyébként.

Ha most akarsz Ipv6 képes gateway-t akkor egy openwrt kompatibilis eszközzel lehet kísérletezni.

( dash | 2010. 04. 02., p – 20:47 )

subscribe

---
Ami a windowsban szarrágás, az linuxban hegesztés.
Ha megszeretted a windowst, tanuld meg használni!
A linux igenis felhasználó-, és NEM idiótabarát.
A linuxot mi irányítjuk, a windows minket irányít.

( gbor | 2010. 05. 29., szo – 14:13 )

Röviden: Ha van valakinek nagyobb kérdése [IPv6!], ami nem "általános", akkor írja ide, stb.

Miért: A kérdéseket továbbítom Ferenc Csorbának/RIPE/oktatóm volt 1 napra nemrég Bécsben, ő kért minket, hogy esetleg küldjünk még kérdéseket [nem feltétlenül ő válaszolja meg, de ismer a RIPE-nál emberkéket, akik mindenre válaszolnak.]

A tag nemsokára kiad egy handbook-ot, amolyan "forgatókönyv" szerűség lesz [átálláshoz, mert tényleg közeleg az idő, és nem mindegy hogy felkészülve fogadja egy cég/isp/stb az IPv6-ot, vagy pedig fejjel megy a falnak a hirtelen felismerés miatt].

Az emberke beszél még Magyarul, szóval úgy is jöhetnek a kérdések [nincs időm fordítgatni Angolra/Németre]

Köszi.

Szeptemberben lesz két budapesti LIR tanfolyam is, az egyik IPv6 specifikus:

LIR Training Course Budapest, Hungary Thursday, September 23, 2010
IPv6 for LIRs Training Course Budapest, Hungary Friday, September 24, 2010

Jelentkezni itt lehet:
https://lirportal.ripe.net/lirportal/training/course-list.html

( csupka91 v | 2010. 07. 16., p – 10:40 )

Sziasztok!

Lehet, hogy bugyuta kérdés lesz, de miért van az, hogy nincsen ipv6-os címem, de mégis tudok csatlakozni ipv6-os címekhez? Win 7-et használok

Szerintem is hasonlóan fog alakulni a helyzet, annyira be vannak rendezkedve a vállalatok és rendszergazdák az IPv4-re, hogy nem fogják eröltetni a váltást belső hálózaton, ha valami miatt nem muszáj. Részben mert nem ismerik az IPv6-ot rendesen, és ha egyszer működik IPv4-el, akkor minek piszkálják alapon..

Ez szerintem rossz, és jó lenne ha terjedne az IPv6, de véleményem szerint belső hálózatokon még sok-sok évig zavartalanul fog működni az IPv4.
--
ahan nem

Ezzel nem értek egyet, hogy miért, az az alábbi példából látszik:
ipv6.google.com egyik címe:
hexában rövidített formában: 2a00:1450:8001::006a
hexában, teljesen kiírva: 2a00:1450:8001:0000:0000:0000:0000:006a
decimálisan ugyanúgy csoportosítva (bár ez nem érvényes címzés): 10752.5200.32769.0.0.0.0.106

És ez egy rövidnek mondható IPv6 cím, ennél mondjuk van rövidebb és hosszabb is. Szerintem hexában átláthatóbbak a címek, és nem ez a "probléma" az IPv6-al, hanem hogy másképp működik. Prefixek, link-local címek, neighbor/router discovery, egy hálózati kártyának sok ipv6 címe lehet, stb stb.

Ezek sem igényelnek komoly intelligenciát, de azért bonyolultabb mint az IPv4, és rá kéne szánni az időt, hogy megismerje és megértse az ember. Ez az ami szerintem az egyik visszatartó erő lesz a váltásnál.

A hip-hop átállás már csak azért sem megoldható, mert IPv4-nél 4 byte egy cím, IPv6-nál meg 16, erre fel kell készíteni a hálózati stackeket és programokat.
--
ahan nem

Végül is mindegy, a használók ellenállásán bukik vagy áll a dolog. Egyelőre az ellenállás az, ami győzelemre áll. Szerintem erre is igaz az, ami minden új dologra. Ha bonyolultabb, nehézkesebb, mint az, amit le akarsz váltani vele, akkor az emberek egyszerűen kikerülik. Vezess be egy új programot vagy ui-t egy 200+ fős cégnél és akkor majd jól egyet fogsz velem érteni. Az IP címet nem megérteni akarják az emberek, hanem használni. A cím itt nem más, mint egy egyedi azonosító, minek ezt bonyolítani, ráadásul más számrendszerbe helyezni? Előnyei? Hátrányai?

Ezzel egyetértek, viszont normális esetben a felhasználóknak nem kell IP címekkel foglalkozniuk, ez a rendszergazda dolga aki beállítja nekik a rendszert.

IPv6 esetén megoldották az autokonfigurációt, legalábbis sokkal kényelmesebb, mint IPv4 esetén. Rádugod a gépet az IPv6 hálózatra és a routolási, címzési és egyéb információkat pillanatok alatt automatikusan megszerzi az alhálozaton elérhető routerektől és szomszédoktól. Ha meghibásodik egy csomópont, elvileg automatikusan újra beállítja a route táblákat, stb. Nem nagyon kell címeket írogatni.

A hexa IPv6 címek előnye, hogy rövidebbek és szebben tagolhatóak, mint másképp lehetne. A szebb tagolhatóság a könnyebb megjegyezhetőség miatt jó.

Hátránya, hogy hosszabb (de ez elkerülhetetlen, mivel a címtér 4 byte-ról 16 byte-ra nőtt), és a hexadecimalitás miatt 0-9 és a-f karakterek lehetnek benne.
--
ahan nem

Ezt mind értem...de leültettem a barátnőmet, aki elolvasta és rögtön megkérdezte:

- akkor vennem kell új routert?
- lehet a mostanival valamit csinálni, hogy menjen?

...és az interneten a jelenlévő on-line résztvevők nagyobb százaléka nem használ rendszergazdát...hát a windowsa is lopott, nem gondolod, hogy majd fizet valakinek?!

Én eddig vállalatok belső hálózatáról beszéltem, előbb még te is ilyet emlegettél: "Vezess be egy új programot vagy ui-t egy 200+ fős cégnél".

Az otthoni felhasználókat kár idekeverni, de mivel Windows XP (ha jól emlékszem) SP2-be bekerült a részleges IPv6 támogatás, és a Vistától kezdve alaptelepítésnél is van IPv6, ezért ha csak nem kapcsolják ki szándékosan, akkor a lanon lesz IPv6 eszköz, akár tudják mi az, akár nem.

Egyébként ahogy az IPv6-ot nem ismerik, az emberek nagy része az IPv4-et sem ismeri.
--
ahan nem

A NAT szerintem most a szükséges rossz. "Muszáj" valahogy megoldani, hogy sokan elérjék az internetet kevés IPv4 cím mögül, és erre pont jó a NAT, de sok probléma van vele, például amikor kívülről akarnak csatlakozni egy NAT mögött lévő gépre.

Az IPv6 kívül IPv4 belül problémára lehet megoldás, például ha az irodának van egy globálisan elérhető 64bites IPv6 prefixe, akkor a routerben ami az internet felé menő kapcsolatokat kezeli, ez beállítható, és ezt a prefixet fogja odaadni minden irodán belüli eszköznek. Ilyenkor a belső hálón lévő gép router discovery segítségével ezt a prefixet megkapja, és esetleg a saját IPv4 címének segítségével (a 64 bites prefix mögött még van 64 bit, amibe az egész IPv4 cím befér) tud generálni magának egy IPv6 címet, ami beállítástól függően az internet felöl elérhető, és a gép is tudja használni az IPv6-os internet címek elérésére.

Ha pedig IPv4-es géppel akar kommunikálni belső hálón, akkor simán az IPv4 címét használja mintha nem is lenne IPv6.

--
ahan nem

Az IPv6-ban, pont az átállás megkönnyítése céljából, lehetőség van IPv4 címeket beágyazni. Így elméletileg lehetséges az IPv6-only endpoint <-> IPv4/IPv6 router <-> IPv4-only endpoint közti routeolás, de konkrétumok nélkül nyilván nem lehet válaszolni a kérdésedre.
--
ahan nem

Vagy inkább Internet felé IPv6, belső hálón IPv6 (publikus cím) ÉS IPv4 (privát cím). Így a belső hálón minden maradhat akár a régi, de a v6-os dolgok is kihasználhatók.

szerk. És külön szűrhetők az Internet felől érkező kérések és a helyi hálózatról érkezők.

Legjobb megoldás nyilván, ha mind a host-ok, mind a szolgáltató támogatják mind a két protokollt (dual-stack). Ilyenkor NAT mögül az IPv4-et NAT-olni kell külső IPv4-re, az IPv6-tal semmit nem kell csinálni. Probléma akkor van, ha vagy a host(ok), vagy a szolgáltató ill. home gateway nem támogatja az IPv6-ot.

Ha a host nem támogatja az IPv6-ot, akkor IPv6 NAT-ot kell használni, ez pl. itt jól le van írva:

http://blog.ine.com/2008/04/18/understanding-ipv6-nat-pt/

Ha a szolgáltató nem támogatja az egész hálózatán az IPv6-ot, akkor 6to4 relay segítségével biztosíthat átjárást a saját IPv4 hálózata és az ő szemszögéből külső IPv6 hálózat között. A különféle tunnel módszerekről itt találtam egy jó összefoglalást:

http://ipv6.com/articles/gateways/IPv6-Tunnelling.htm

( Gorkhaan (nem ellenőrzött) | 2010. 10. 23., szo – 12:28 )

Tud valaki egy relatíve olcsó IPv6-os címet nyújtó szerver hostingot? Thx.

|| "Software is like sex: it's better when it's free." Linus Torvalds || Visit Gorkhaan's Homepage

A Dataplex ISP független adatközpont.
Jelen vannak: Magyar Telekom, Invitel, GTS, AT&T, Telekom Austria, Interoute, Antenna Hungária, British Telecom, Quaestel, Datek Telecom, Linxtelecom, Telia-Sonera, Level3, MVM, Siemens-Trafficom, Novotron, Cogent, DIGI, UPC, Telefonica, Telenor, Proserver, CSINFO, RetNet.
Gyakorlatilag attól veszed a linket akitől akarod.

A Dataneumben nem tudom ki van jelen (az Invitel biztosan), de szerintem oda is becsorognak lassan az ISP-k.

***
programozó nők rémálma: a végtelen ciklus

http://serverhome.hu/ itt van a hostoffice oldala. En errol a kettorol tudok csak hogy foglalkozik v6al. Amit jakubovics probal javasolni az inkabb nagyobb cegeknek valo (min. terulet amit lehet berelni DPben 1 rack szekreny (42u) aztan pedig veszel valakitol savot, ez nyilvan nem egy 15+fa/ho lesz 0 huf indulokoltseggel.)

Nos, 3.-án írtam pár hostinggal is foglalkozó cégnek: Interware, Invitel, Matáv és Proserver.
Az automata válaszok az Inviteltől és a Matávtól jöttek, hogy fogták az adást.
Elsőnek az Invitel válaszolt, hogy bocsi, de egyelőre nincs. Bár hozzájuk akkor se mentem volna, ha IPv10-et adnának már most.

Utánuk az Interware és a Proserver válaszolt hasonló értelemben (nincs, és még nem tudjuk, hogy mikor, illetve hogy érdeklődés hiányában az IPv6 egyelőre elmarad).

A Matáv (természetesen) még nem válaszolt.

Értem én, hogy tehetnék olyat, hogy veszek placcot valakitől, és drótot másvalakitől, de mivel kevés szerverem van, ez nekem nem pálya. Nomeg a francnak van kedve két szolgáltatóval szórakozni, néha egy is sok(k).

C'est la vie

Update: kerek egy héttel a kérdés után válaszolt a Matáv is. Ők viszont tudnak adni IPV6-ot, a Dataplexben. Sőt, mondhatni még örülnek is neki, hogy valaki teszteli használja az IPV6-os hálózatukat.

( gbor | 2010. 12. 03., p – 12:17 )

"A tag nemsokára kiad egy handbook-ot, amolyan "forgatókönyv" szerűség lesz"

"nemsokára" kijön a forgatókönyv, addig is adott egy pár linket: 


http://getipv6.info/index.php/First_Steps_for_ISPs
http://www.a10networks.com/forms/register.WP-IPv4_IPv6.php
http://www.ja.net/documents/publications/technical-guides/ipv6-tech-guide-for-web.pdf
& "IAB Thoughts on IPv6 Network Address Translation
http://www.rfc-editor.org/rfc/rfc5902.txt
e.g. http://getipv6.info/index.php/Operational_transition_information
http://getipv6.info/

As the source for many links I can recommend http://IPv6ActNow.org

Campus-specific:
http://www.6deploy.org/tutorials/131_Campus_IPv6_deployment_consideration_v0_6.pdf

> Can you also recommend some training materials that I can use to create
> some internal training for IT Support staff within the University?
> Typically these staff just support end-user systems, mainly desktops and
> the occasional server; they don't need to know anything about routing etc.

Here are some helpful IPAM Tools:
   * IPAT (IP Allocation Tool)   http://nethead.de/index.php/ipat
   * NetDot     https://netdot.uoregon.edu/trac/
   * HaCi     http://sourceforge.net/projects/haci/
   * FreeIPdb      http://home.globalcrossing.net/~freeipdb/
   * Infoblox IPAM Freeware
http://www.infoblox.com/services/infoblox-ipam-freeware.cfm

DNS & Reverse:
   http://tools.ietf.org/html/rfc4472
   http://tools.ietf.org/html/draft-howard-isp-ip6rdns-03

From the ISP perspective:
   * Scenarios and Analysis for Introducing IPv6 into ISP Networks
http://tools.ietf.org/html/rfc4029

   * First steps for ISPs
http://getipv6.info/index.php/First_Steps_for_ISPs

   * Emerging Service Provider Scenarios for IPv6 Deployment
http://tools.ietf.org/html/draft-ietf-v6ops-isp-scenarios-00

And some links - I hope you will find what you need in some of them:

"Books" / papers:
=================

* A free book!
http://icons.apnic.net/download/attachments/983220/The+Second+Internet.pdf?version=1

* "The End of IPv4? Migration paths to IPv6"
downloadable from here:
http://www.a10networks.com/forms/register.WP-IPv4_IPv6.php

Here are some other websites with useful information:

ARIN's wiki:
http://getipv6.info

E-learning:
http://www.6diss.org/e-learning/index.html

Tutorials: (pdf)
http://www.6diss.org/tutorials/

Very "technical" - RFC that mentions all the other RFCs:
http://tools.ietf.org/html/draft-ietf-6man-node-req-bis-03

Miscellaneous:
http://www.ripe.net/ipv6-address-types/

http://www.quicklycode.com/cheatsheets/ipv6-cheat-sheet

Also, in case you have specific technical questions about IPv6, we
recommend you to join the IPv6 ops mailing list:
http://lists.cluenet.de/mailman/listinfo/ipv6-ops

( Zaneck | 2010. 12. 28., k – 11:32 )

Epic comment is epic at Slashdot:

Remember before Y2k almost all computer manufacturers placed "Y2k Compliant" or "Y2k Ready" logos on everything from bare computer cases to speakers? Well I cant wait for my "IPv6 Ready" USB keyboard...

( Zoltan1992 | 2011. 01. 22., szo – 15:12 )

http://ipv6.ircnet.hu/index.php

"Üdvözöllek, te vagy a 9807. látogató, aki megnézte Magyarorszag első tunnel broker oldalát!"

Eddig nem rendelkezik nagy látogatottsággal az oldal. Viszont szerintem érdemes megnézni, jó leírások, magyarul. :-)

Ja, szóval bugos. Egyébként a menü az működik nálatok? Akárhova kattintok mindig ugyanaz jön be. Egyedül a "Fórum" és a "Ping Stat" működik a menüben.
Lehet, hogy még erősen fejlesztés alatt van az oldal.. Csak akkor azt nem értem, hogy miért rakták ki így a nagy publikum elé?

hat az ISPk azok valoszinu, hogy carrier-grade-nat-al fognak dobalozni az elejen egeszen addig amig nem lesz olyan epkezlab CPE ami tud IPv6-ot. Szoval nem lesz itt meg IPokalipszis majd kicsit kesobb amikor a tartalomszolgaltatok nem fognak tudni IPv4-et szerezni vagy venni. Akkor majd elkezdenek szepen lassan atallni.

mondj egyet ami tud v6-ot es raadasul meg routol is gyari firmwarerrel. Linksys wrt54gl-t neztem nekem nem sikerult v6-ra szokatni a gyari softtal es a ddwrt-vel is kuszkodni kell. En eddig meg egy home routerbe se lattam v6-ot mint beallitas.

ARIN idevonatkozo wikije: http://getipv6.info/index.php/Broadband_CPE

( madmartigen v | 2011. 01. 25., k – 14:31 )

New Yorkban kérdeztem internetszolgáltatókat (nevesen 2-t), hogy lehet-e igényelni az internetelőfizetéshez IPv6-ot. Az első technikustól kérdeztem semmit nem erőlködtem, csak mégis mi az ábra. A válasz, nincs. Miért? Nem elterjedt, nem szabvány. Ilyen válaszokat kaptam. És tárhelyszolgáltatóknál is hasonló válaszokat mondanak. Pl godaddy is.

Ez valoszinu, hogy piacra fog kerulni es a cegek elkezdik adni venni tekintve, hogy ezeket a /8 es tarsait az IANA osztogatta meg anno szoval lehet vele csinalni barmit.

Ha most IPcim kell neked akkor innen hasznalhatsz egy par egyiptomi prefixet ok most ugyse hasznaljak:) (https://labs.ripe.net/Members/rbarnes/visualizing-the-egyptian-disconne…) csak arra kell vigyazni, hogy ne olyat hasznalj ami most is hirdetve van, mert akkor bajban lesz a tozsde:)

Mellesleg kiosztottak az utolso szabadon oszthato /8-at az IANAbol szoval nem kell sokat varni es kiderul, hogy mi is lesz itt: http://www.networkworld.com/news/2011/020111-address-allocation-kicks-o…

( talisker | 2011. 01. 26., sze – 15:14 )

subscribe
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)

( Fisher v | 2011. 01. 28., p – 13:13 )

Gondolom alap kérdés, de én kb. hétfőn kezdtem foglalkozni az ipv6-al, úgyhogy bocsi.

Az alapvető problémám:

PING ipv6.google.com(2a00:1450:8007::6a) 56 data bytes
From fe80::219:dbff:fecb:181a icmp_seq=1 Destination unreachable: Beyond scope of source address

A nyomor oka alighanem az, hogy:

inet6 addr: fe80::a800:4ff:fe00:a04/64 Scope:Link

Ha jól értem a scope szerepét, akkor meghatározza, hogy egy-egy cím merre, meddig érvényes, azaz a fenti esetben az adott hálózatra, ami fe80::ffff:ffff:ffff/64, ha jól vágom.

Update:

ip -6 route
fe80::/64 dev eth0 metric 256 mtu 1500 advmss 1440 hoplimit 4294967295
default via fe80::219:dbff:fecb:181a dev eth0 proto kernel metric 1024 expires 0sec mtu 1500 advmss 1440 hoplimit 64

Namost. Minek ez a scope? (Jó, látom értelmét, ezen még túltettem magam). A gépem most stateless konfigot kapott, ha azt akarom, hogy a scope ne link (local?) legyen, hanem global(?) akkor mit tegyek? Statikus konfig? DHCP?

Konkrét válasz, vagy link, bármi jöhet :D

Áhm, akkor leírom részletesebben, mert persze a lényeges dolgokat kihagytam.

Van egy gw, rajta a miredo, az frankón lát mindent, hirdetem rajta radvd-vel a routingot, gw-t, a kliens fel is veszi a route-ot, ám a probléma mint fent. Azaz link local címet kap, ami ha jól értem nem remek.

A következőket gondolom:

- a miredo "mögött" nem tudok csinálni global címet, de miért ne?
- vagy tudok csinálni, csak nem úgy, ahogy én csinálom :D

( bujdi | 2011. 01. 29., szo – 22:29 )

Hogyan is néz ki az átállás jelenleg a tűz közelében ülő szakember szemszögéből. Geoff Huston az APNIC-nak dolgozik. Saját bevallása szerint sem optimista ember, de _elég borús_ képet fest az előttünk álló évek/évtized-ről. Nagyon remélem, hogy nem lesz igaza, persze a remény hal meg utoljára.

Röviden: Nincs megoldás. (sem carrier grade NAT, sem egyéb megoldás nem működik élesben... próbálták.) A v4 címek pedig elfogy(tak|nak).

2011 Linux Conf Australia-n hangzott el a keynote:
http://blip.tv/file/4692762/
Azt hiszem, hogy akit érdekel a téma érdemes végignéznie.

( fdavid | 2011. 02. 02., sze – 16:30 )

Nagyon sok minden elhangzott es jo ez a FAQ is, de valahogy meg midnig egy csomo kerdesem maradt, pedig igyekeztem egy kicsit kutakodni a neten.

Megprobalom a jelenlegi ismereteimet atekintetben osszefoglalni, hogy mit is kellene egy foldi halandoanak tennie az ipv6 atallassal kapcsolatban, es akkor majd johet FIXME.

1. Ha jol ertem technikailag a ket halozat tudna ugyanazon az infrastrukturan parhuzamosan, egymastol fuggetlenul mukodni, de ehhez minden interfacet dual modba kellene konfiguralni. Alternativakent leteznek meg kulonfele gateway megoldasok, amik atjarast biztositanak a ket halozat kozott. Allitolag ez a dualitas a gyakorlatban nem mukodik megfeleloen a fallback tul nagy timeout utan tortenik, sok varakozas, szivas, stb.

User oldalon: sajat rendszert fel kell kesziteni ipv6-ra. A sajat eszkozeimet meg talan fel tudnam esetleg, de mi van a szolgaltatotol kapott adsl routerrel? Nem birtam semmit kideriteni rola. Persze ez legyen a szolgaltato baja, de azert megis erdekelne.

ISP oldalon: lehetoseg kell legyen ipv6-os cimet is kapni. Errol sem tudtam az internet es informaciok alapjan semmit kideriteni. (Ausztria) Barmire keresek, csak 2004-es ontomjenezes jon le, hogy mar mennyire allati jol haladunk az atallassal. Azota semmi.

Webhost oldalon: ipv6-on is szolgaltatni kell. Inmotionhostingot hasznalok, nem birtam a neten informaciot talalni arrol, hogy szolgaltatnak-e ipv6-on.

Ok, lehetne az ugyfelszolgalatokat kerdezgetni, de hat amikor a napokban rakerdeztem az ISP-nel, a kislany csak annyit kerdezett vissza, hogy ip-micsoda??? Mondtam, hogy jo, nem erdekes. Valahogy furcsa, hogy kongatjak a veszharangokat, de a szolgaltatok valahogy nem izgulnak az ugyben. Nincsnek nyilvanos informaciok, howtok, tippek. Minden a legnagyobb rendben, nincs itt semmi latnivalo.

2. Ahhoz, hogy valaki ipv6-os halozaton tudjon mukodni, ipv6-os szoftverek szuksegesek. Ez minden olyan szoftverre igaz, amelyik kozvetlenul hasznalja a halaozati reteget. Itt nagy kerdes, hogy ez a szoftver atallas valojaban mit is jelent. Hogyan tudja egy user felmerni, hogy mik is ezek a szoftverek, es mi a szukseges konfiguracios valtoztatas. (iptables, nmap, postfix, apache, stb) Ki vannak ezek megfeleloen tesztelve ipv6-os modban? Hogyan kell pl. az iptables szkriptemet ipv6-ra atirni? Jok leszenk uyganazok a szurok? Mas szurok kellenek? (ping, state, ???)

Nekem szemely szerint hianyzik egy ertelmes, jol kovetheto migracios utmutato, mert az baromi keves, hogy hol regisztraljak tunnelingre, es hogy huzzak fel egy ipv6-os interfacet.

"gondolom": igény nincs rá, mivel nincs érdemi szolgáltatás, ami az ipv6 hiánya miatt nem lenne, ergó nem hozna a konyhára, ergó "majd akkor mozdulok rá, ha profitom is lesz belőle" - címszó alatt lesz*rják a döntéshozók.

p.s.: akit érdekelnek hírek a nagyvilágból ipv6 terén, az már feliratkozott a topicra, néha megpróbálok elcsípni 1-2 hírt

e.g.: pont most volt.:

Comcast Activates IPv6 Trial Users
http://tech.slashdot.org/story/11/02/01/2314252/Comcast-Activates-IPv6-…

p.s.2: CTRL+F-el rákerestem a "?"-ekre a bekezdésedben:

de mi van a szolgaltatotol kapott adsl routerrel? - asszem ez egy külön téma, és csere kell, ha nem fw update

a kislany csak annyit kerdezett vissza, hogy ip-micsoda? - így már én is jártam:D csak én elmagyaráztam neki, és épp ebédidő előtt telefonáltam az ügyfélszolgálatra, így ha van közös kajaidő-szerűségük, akkor lehet, h. beszédtéma volt az ipv6, így nagyobb az értelme kérdezősködni ügyfélszolgálaton

Ki vannak ezek megfeleloen tesztelve ipv6-os modban? - nem hinném :D ki tudja, h. 10 év múlva találnak vmi hibát, és jól megszívja mindenki

"Hogyan kell pl. az iptables szkriptemet ipv6-ra atirni? " - gondolom majdhogynem ugyan úgy, ip6tables előtag
[még nem kellett sajnos ipv6-on tűzfal szabályokat készítenem értelmes helyen, de a man-t átnyálazva 2 perc alatt nincs érdemi különbség, icmp-t engedélyezni]

én még sajnos csak teredozom :(

Nos a programokról annyit, hogy ép eszű programozó legalább 5 éve úgy csinálja a programját, hogy ipv6-on is tud hallgatni, konnektálni, stb. Amelyik nem, az nem épeszű... Most a bugokat hagyjuk, persze ő hiába teszteli v6-on, meg esetleg másik 2 haverja még, a rejtett bugok akkor szoktak előjönni, amikor tömegek használják.

ipv6-os iptables ruleokat ugyanúgy kell írni, ugyanazok a szabályok vonatkoznak rá, annyi, hogy icmp-ket engedni kell.
--
Discover It - Have a lot of fun!

( hrgy84 | 2011. 02. 03., cs – 00:07 )

Elkezdtem ossszeloni az IPv6-ot az itthoni halon, de nyuglodok vele nagyon.

A kovi a topologia: 


          ADSL          NAT
{Internet} -- {OpenWRT} --- NetBSD

Az OpenWRT a NetBSD default gateway-e, de mindenki mas a NetBSD-t hasznalja default gatewaynek, mert o belat olyan helyekre is, ahova az OWRT nem (VMware halok, bonyolult, lenyeg, hogy igy van).

Tekintve, hogy az OpenWRT-t nem nagyon csesztetnem ilyenekkel (plusz LuCI-bol nem is annyira tudom managelni), arra gondoltam, hogy a NetBSD-n lovom ossze ezt a reszet, es a routernek akkor csak a v4 reszevel kell a dolognak foglalkoznia.

A he.net -et valasztottam brokernek, az altaluk adott BSD oldali konfig ilyen: 


ifconfig gif0 create
ifconfig gif0 tunnel 91.120.158.197 216.66.84.42
ifconfig gif0 inet6 2001:470:1f12:5e5::2 2001:470:1f12:5e5::1 prefixlen 128
route -n add -inet6 default 2001:470:1f12:5e5::1

Ez alapvetoen jo is, a NetBSD elfogadja, doksik alapjan is valami ilyesminek kell lennie, sajat magamat tudom ping(6)-etni, a broker szerver is valaszol IPv4-es pingre.
Ami a gondom, az az, hogy a vilag IPv6 resze viszont szarik ram, mar a brokeremet se tudom ping(6)-etni . Mar ott tartok, hogy ledozeroltam a WRT tuzfalat, a NetBSD-n a pf-et, a 41-es protokollt direktbe beforwardolom a NetBSD-nek, de semmi. Nem erzem, hogy valami tortenne. Amit latok, az az, hogy a routerig eljutnak a dolgok, logban szepen megjelenik a v6 forgalom, viszont mintha tovabb nem akarna jonni a dolog.

IP topologia:
NetBSD: 192.168.2.20
WRT: 192.168.2.1

NetBSD oldalon tuzfal nincs (pf -d)
OWRT oldalon a tuzfal az alabbi (nincs iptables-save benne, ugyhogy csak ilyen kimenet van): 


Chain INPUT (policy ACCEPT 2138 packets, 273K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 7835 packets, 2873K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 1294 packets, 281K bytes)
 pkts bytes target     prot opt in     out     source               destination         

################################ NAT ##########################################
Chain PREROUTING (policy ACCEPT 2576K packets, 297M bytes)
 pkts bytes target     prot opt in     out     source               destination         
 833K   64M zone_wan_prerouting  all  --  ppp0   any     anywhere             anywhere            
1751K  234M zone_lan_prerouting  all  --  br-lan any     anywhere             anywhere            
2576K  297M prerouting_rule  all  --  any    any     anywhere             anywhere            

Chain POSTROUTING (policy ACCEPT 7910 packets, 381K bytes)
 pkts bytes target     prot opt in     out     source               destination         
1309K  116M postrouting_rule  all  --  any    any     anywhere             anywhere            
1309K  116M zone_wan_nat  all  --  any    any     anywhere             anywhere            

Chain OUTPUT (policy ACCEPT 5502 packets, 508K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain postrouting_rule (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain prerouting_lan (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain prerouting_rule (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain prerouting_wan (1 references)
 pkts bytes target     prot opt in     out     source               destination         
  196 11496 DNAT       tcp  --  any    any     anywhere             anywhere            tcp dpt:443 to:192.168.2.4 
    0     0 DNAT       tcp  --  any    any     anywhere             anywhere            tcp dpt:2022 to:192.168.2.20:22 
    0     0 DNAT       tcp  --  any    any     anywhere             anywhere            tcp dpt:1194 to:192.168.2.20 
 5765  242K DNAT       udp  --  any    any     anywhere             anywhere            udp dpt:1194 to:192.168.2.20 
    0     0 DNAT       tcp  --  any    any     anywhere             anywhere            tcp dpt:6881 to:192.168.2.172 
    0     0 DNAT       tcp  --  any    any     anywhere             anywhere            tcp dpt:6882 to:192.168.2.175 
   60  2772 DNAT       tcp  --  any    any     anywhere             anywhere            tcp dpt:3389 to:192.168.2.5 
 1516 85176 DNAT       tcp  --  any    any     anywhere             anywhere            tcp dpt:80 to:192.168.2.4 
    0     0 DNAT       tcp  --  any    any     anywhere             anywhere            tcp dpt:902 to:192.168.2.4 
    0     0 DNAT       tcp  --  any    any     anywhere             anywhere            tcp dpt:8222 to:192.168.2.4 
    0     0 DNAT       tcp  --  any    any     anywhere             anywhere            tcp dpt:8333 to:192.168.2.4 
    0     0 DNAT       ipv6 --  any    any     anywhere             anywhere            to:192.168.2.20 

Chain zone_lan_nat (0 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 MASQUERADE  all  --  any    br-lan  anywhere             anywhere            

Chain zone_lan_prerouting (1 references)
 pkts bytes target     prot opt in     out     source               destination         
1751K  234M prerouting_lan  all  --  any    any     anywhere             anywhere            

Chain zone_wan_nat (1 references)
 pkts bytes target     prot opt in     out     source               destination         
1301K  115M MASQUERADE  all  --  any    ppp0    anywhere             anywhere            

Chain zone_wan_prerouting (1 references)
 pkts bytes target     prot opt in     out     source               destination         
 833K   64M prerouting_wan  all  --  any    any     anywhere             anywhere

Nem tudom, mit rontok el. Feldobtam az ipv6 modult a WRT-re, de semmi hatasa. Mondjuk, nem remeltem sokat tole, mert elvben ugye a WRT csak a v4 oldalat latja a dolognak.

Help.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Igen-igen.

A vegen kiderult, hogy en voltam a hulye. Nem olvastam el az aprobetus reszt, ami emigyen szola:

*NOTE* When behind a firewall appliance that passes protocol41, instead of using the IPv4 endpoint you provided to our broker, use the IPv4 address you get from your appliance's DHCP service.

-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Biztos lehet, nekem ezt dobta a gep, en meg csak most ismerkedek vele.

Ami a nyug, hogy ugyan mar tudok a BSD-rol ping(6)-etni, de nem tudom a tunnelt tovabbosztani, egyszeruen valahogy nem maszik be a fejembe, hogy ez most hogy routolodik.

Fellottem az rtadvd-t, ami ugye elvben az ipv6 autokonfiguraciot hirdetne be a halozaton, ez tok faszan el is indul, de a kliens (egy laptop, wifivel) sehogy se akar konnektalni.

A masik amit nem nagyon ertek, hogy bekonfoltam magamnak kezzel a laptopra az ipv6-ot, meg is tudtam pingetni a BSD-t, azt annyi. Elvben mivel ezek kulon alhalo, akkor ide is fel kell konfigolni a... nem tudom minek nevezzem, jobb hijan NAT-nak... szoval a NAT-ot? Mert egymas melletti /64 -eket kaptam (az egyik a tunnel oldali netem, a masik amit tovabboszthatok), de ezekbol gondolom nem fogja senki kitalalni, hogy osszetartoznak. Jo helyen tapogatozok?
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

ertem. De akkor viszont nem ertem, miert nem megy:
1) A laptop (wifis) nem vesz fel automatan ipv6 cimet annak ellenere, hogy hirdetve van a subnet
2) Ha kezzel bekonfigolom, akkor, meg ha routernek be is allitom a BSD-t, akkor sem tudok ping(6)-etni.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

1, Nos akkor azt kéne megnézni, hogy engedélyezve van-e az ipv6 autokonfiguráció: net.ipv6.conf.all.autoconf. BSD-n is hasonló. Winen fogalmam sincs.
2, akkor valszeg az radvd konfig nem jó. Egyébként ha most kérted a subnetet a sixxs-től, akkor arra azt írják, hogy várj pár napot, amíg ténylegesen feléd lesz routeolva a subnet... Szóval türelem.
--
Discover It - Have a lot of fun!

Tehát van összesen 5 adatod:
-tunnel HE v4 végpont
-tunnel nálad v4 végpont
-tunnel HE v6 végpont
-tunnel nálad v6 végpont
-És egy tartomány ami /64

Sajnos nincs tapasztalatom BSD-vel, de ahogy látom az rtadvd lényegében egy radvd.
Gondolom megadtad neki a /64es tartományt kérdés miért nem hirdeti, logban nincs valami?

ipv6_gateway_enable="YES" be van lőve?

ehh,

Buffer owerflow detected, route terminated...

Viszont az ip -6 route megcsinalta. Koszonom, ez volt a megoldas.

Szerk: Utana megjott a hirdetestol is az IP cim, mindjart rebootlok egyet, hogy mit csinalunk ugy.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Sikerült megoldani végül a dolgot?

he-tunnel
Client IPv6 address: 2001:470:1f12:68b::2/64
Routed /64: 2001:470:1f13:68b::/64
eth0 fixIP net felé
eth1 fixIP LAN felé (192.168.0.247)

Én jelenleg ott tartok, hogy a GW-nek használni gépen megy az IPv6.

# mtr hup.hu
1. djsilas-1.tunnel.tserv10.par1.ipv6.he.net
2. gige-g2-3.core1.par1.he.net
3. 10gigabitethernet1-3.core1.lon1.he.net
4. 2001:7f8:4::ddd:1
5. 2001:450:2002:fa::2
6. 2001:4c48:0:1::1
7. v6lns-ip3-gi-0-0-3507.ipv6-tst.telekom.hu
8. 2001:4c48:1:f800::6

# ping6 ipv6.google.com
PING ipv6.google.com(2a00:1450:8007::6a) 56 data bytes
64 bytes from 2a00:1450:8007::6a: icmp_seq=1 ttl=57 time=47.8 ms

Gondolom nem feltétlen kell használni radvd -t (ahogyan DHCP sem kötelező), hanem megadhatom kézzel is az adatokat. Na de mégis mit mondjak a laptopnak, hogy menjen az IPv6? Mert ezt nem sikerült még kitalálnom...

Ha meg mégis kell a radvd, akkor meg miért nem megy!? Mert hogy azzal sem boldogultam... :(
# cat /etc/radvd.conf
interface eth1
{
AdvSendAdvert on;
prefix 2001:470:1f13:68b::/64 {
AdvOnLink on;
AdvAutonomous off;
};
};

Az ip6 tunnel használ valami portot, azt nem kéne forwardolni a bsd-re?
Szerintem igen.

Ez meg komoly? tényleg így van?

"Chain INPUT (policy ACCEPT 2138 packets, 273K bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 7835 packets, 2873K bytes)
pkts bytes target prot opt in out source destination "

Nem, a teszt miatt volt igy.

Portot nem hasznal, pontosabban olyant nem hasznal, ami ne lenne beengedve (mivel a BSD a kezdemenyezo, a sima tuzfalon a connection tracking miatt atmegy).

A proto 41 az, amit at kell adni a BSD-nek direktben.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Milyen routered van ?
ha van még annyi szabad helyed, rakj fel egy aiccu, radvd párost (és persze ipv6 támogatást)
http://wiki.openwrt.org/oldwiki/IPv6_howto

Nekem ezt custom openwrt-vel (imagebuilder, mégcsak forgatni sem kell), sikerült még WRT54g(l)-be is beletuszkolni bind-clinet(nsupdate), openvpn mellé :).
TPLink 1043ND-ra mégcsak imagebuilder sem kell, opkg-vel csomagok fel és kész.

Az lehet a gond hogy tunnelnek netbsd-n publikus ipv4-es IP-d adod meg, az pedig WRT-n van, valamit WRT nem forwardol (proto 41.ipv6-hoz kell, tunnelhez lehet hogy más is kell)

illetve próbáld meg ezt:
ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/net/aiccu/README.html

Ez NAT-olt hálózatból is műkődik, nem néztem kit használsz tunnel brokernek, de SIXXS nagyon régóta megbizható.

( PunishR v | 2011. 02. 03., cs – 00:56 )

Jó lenne Hálózatok alá egy IPv6 kategória is lassan, ami alá mehetnének az ezzel kapcsolatos topicok, ez egy kicsit kezd átláthatatlanná válni.

( hawk | 2011. 02. 03., cs – 12:07 )

Lehet buta kérdés(ek), de akkor is felteszem.

Magyarországon T-csoporton kívül hosting céllal oszt már valaki IPV6-ot és ha igen mik a tapasztalatok vele??

T-csoport tudtommal még nem oszt, kivéve hup/fsn/freemail.

Amennyiben szerverhostingra célzol akkor ATW és HostOffice oszt.

ATW teljesen nativan ad még a legkisebb VPS-hez is egy /56-ot és szépen BIXen át forgalmaz is.

HostOffice-nál egy /48-at kaptam a saját tartományukból nativan, de ők valamiért HE.net át forgalmaznak még.

Más cégről nem tudok.

( uid_15480 v | 2011. 02. 03., cs – 12:07 )

Sziasztok!

Az itt emlitett stage 4-be mikor jutunk el? Ugye ott mar csak IPv6-os cimek lesznek. Mil esz azokkal akiknek meg v4-es cimuk van? (UPC), es mikor kezd el szolgaltatni a UPC v6-os cimeket a nagykozonsegnek?

Udv. bnv

( uid_16313 | 2011. 02. 13., v – 15:35 )

Elképzeltem egy tiszta ipv6 alapú világhálózatot...

Mivel ipv6 alapon nincs NAT, ezért minden az Internetre csatlakozó számítógép dedikált címet fog kapni.
Ezután meg egyből arra gondoltam, hogy ez jó okot ad majd arra, hogy a magyarországi internetszolgáltatók plusz pénzeket kérjenek minden egyes internetre csatlakozó eszköz után - ami ugye a NAT-nál nem működik jelenleg.

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

A normálisan működő Kapitalizmusban a Fogyasztó az "Isten", mert belőle él a Szolgáltató.
A nem normálisan működő "Kapitalizmusban" ez pont fordítva van.
Sajnos sokszor csak a "nyers" technológia érkezik meg kis hazánkba, a hozzá való "mentalitás" kint marad.
Sajnálatos módon.

Szerintem a jelenlegi, magyarországi "Internet-szolgáltatók" etikailag legvitathatóbb "húzása", hogy csak az számít új előfizetőnek, akinek a telefonvonalán 3 hónapon belül nem volt ADSL szolgáltatás. Tudom mi van a háttérben, direkt nem írok cégneveket. Persze 12 hónap hűségidő, beetetési áron, utána már soha többet nem kapod ugyanannyiért.

Szerintem ez simán kimeríti a diszkrimináció fogalmát. A szolgáltatás ugyanis ugyanaz marad.

Az is etikátlan, hogy még mindig telefon előfizetéshez kötik az ADSL-t, illetve az árakat úgy kalkulálják, hogy az anélküli se legyen kedvezőbb, viszont el lehet mondani, hogy van olyan is.

Normális esetben VALÓDI verseny lenne a piacon, nem kiszolgáltatottság, és a Szolgáltatók között a szolgáltatás ára, és minősége döntene, nem a mesterséges, etikátlan jogi ügyeskedés.

Na Trey, ha átléptem azt a bizonyos határt, úgyis kitörlöd majd a hozzászólásomat, és bocsánat a nagybetűs /OFF-ért!

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

( dash | 2011. 03. 10., cs – 22:58 )

IPv6-on 4 darab oktett helyett 8 darab micsoda van? Quartett??

----------------------------
színes ingyen domain domain

( Fisher v | 2011. 04. 20., sze – 13:29 )

Gyakorlati kérdésem van, és szégyen, nem szégyen elvesztettem a fonalat, pláne hogy most épp viszonylag problémásan tudnék tesztelni.

Új szerver hostingra készülök, és ha már új gép, akkor legyen meg legalább a lehetősége az IPv6 címek használatának is. Viszont amivel elkavarodtam:

- a T-systems 2 IP címet ad (IPv6), bármit is jelentsen ez
- kérésre adnak egy /60-as tartományt, ami bőven rengeteg
- az atw alapból /64-et ad

A gépen OpenVZ konténerek vannak, és ha már IPv6 akkor legyen nekik is "rendes" v6-os címük, még ha ez nem is olyan egyszerű.

Ahogy én látom:

- elég lehet egy IPv6-os cím is, mert akkor a konténerek csak link-local címeket kaphatnak majd
- de ha van egy tartomány, akkor lesz (lehet) global és link-local címük is.

Jól látom? :D

Nem probléma, mert proxy nélkül amúgy se akarom a konténereket kirakni a nagyvilágba. Bár most az smtp miatt elbizonytalanodtam, hogy tuti lesz olyan, amit muszáj lesz, lenne.

A matvánál még nem tudtam technikai embert elérni, a legutolsó információm az az, hogy vagy kettő vagy /60, de már folyik az egyeztetés.

Tisztult a kép, ára lett a dolognak.

A T-Systems bő ezer forint/hó/db áron akar adni 1-1 plusz IPv6-os címet, és majd 20-ért egy /60-as tartományt ami megítélésem szerint szimpla rablás.

Pláne abban a fényében, hogy IPv6 alatt nincs nat (fixme, az ipv6-com most nekem ilyet mond: Connection to 216.138.235.55 Failed), tehát egy címmel kb. kitörölhetem.

( kalebris | 2011. 06. 08., sze – 09:30 )

IPv6 gameday van ma. BIX-en latszik. 9x-el nott az v6 forgalom a BIX-en. Kivancsi vagyok mi is ez a forgalom p2p vagy valami egyeb tortent.

( zolij | 2011. 06. 13., h – 11:55 )

Tegnap beállítottam az itthoni hálózatra (pirelli home gateway, a v6-hoz debianos gw, windowsos gépek) a t-s leírás alapján az ipv6-t és feltűnt, hogy a t-s nameserverek a google-s szolgáltatásokra továbbra is az AAAA rekordot adják vissza, pedig elvileg a google kiszedte az IPv6 világnap után (és más nameservereknél el is tűntek a rekordok).
Ötlet, hogy ezt mi okozhatja? Ilyen nagy cache lenne a t-s nameservereknél?

Ez vajon azt jelenti, hogy a levelezésre is bekapcsolják?

Tapasztalatom szerint azzal nagyon sokan megszívják (a hozzánk ipv6-on beeső kapcsolatok exhas 90%-anak nincsenek az alap dolgok beállítva, mint ptr, nem tunnelen megy ki, stb.)

Mondjuk személy szerint örülök neki, lesz kivel ipv6-n kommunikálni a gépeknek :D

Az SLAAC-t a rosszul beállított (hiányzó PTR) kliensekre írtam.

Érdekes kérdés, hogy ha /64-et, illetve /56-ot adnak a szolgáltatók a usernek, vajon hogy biztosítják a PTR-ek (reverse DNS) hozzárendelését. A fenti tartományokból ugyanis a user dönti el, hogy a prefix mögé "mit tesz", azaz elvileg mind a 2^64, illetve 2^72 IP címre be kellene regisztrálni két rekordot (AAAA és PTR).

A legelterjedtebb autoritatív NS-ek (pld. bind, nsd) memóriában tartják a zónákat, így könnyen kiszámolható, hogy csak egyetlen userhez rendelt /64 és /56 összes AAAA és PTR rekordja annyi memóriát igényelne, amennyi valószínűleg storage-ból nem készült összesen mióta ilyeneket gyártanak. Nem jó tehát a diszk alapú tárolás (pld. az adatbázis alapú névszerverek) sem, marad tehát az, hogy nem adnak AAAA-t és PTR-t, vagy csak egy pár (általuk meghatározott címre adnak), vagy olyan névszervert használnak, amely adatbázis nélkül találja ki, hogy a beérkező hostnévre/IP címre mit kell visszaadni.

Ez az RFC foglalkozik részletesen a problémával.

Hogy miért nem engedélyezi a google az mx recordokat, arról fogalmam sincs.

A tesztoldal

https://ipv6test.google.com/

mit néz?

Nem észleltünk problémát.

Ön nem rendelkezik az IPv6-tal, de nem lesz problémája az IPv6-ot használó webhelyeken.

Csak link-local IPv6 címem van, viszont találtam egy ilyent:

Teredo is an automatic tunneling technique that uses UDP encapsulation and can allegedly cross multiple NAT boxes.[43] IPv6, including 6to4 and Teredo tunneling, are enabled by default in Windows Vista[44] and Windows 7. Most Unix systems implement only 6to4, but Teredo can be provided by third-party software such as Miredo.

Holnap megnézem Linux -szal is.

Link local címmel nem érsz semmit, azzal nem tudsz netre menni, meg egyáltalán route-olni sem lehet. Azzal a veled egy subnetben lévő gépekkel tudsz kommunikálni.
Javaslom valami ipv6 basics and addressing elolvasását :).

Win7-en van teredo, de csak akkor megy azon keresztül, ha kifejezetten kéred hogy v6-on menjen, vagy pedig az adott domainnek csak v6 címe van.
--
Discover It - Have a lot of fun!