/56-os forradalom - IPv6 otthonra

Címkék

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.

Hozzászólások

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...

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!

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

subscribe

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

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

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.

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.

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, ...

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” :)

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

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

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.

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"

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

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

--
xterm

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? :)

(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).

> 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?

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?

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…

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

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

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..

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?

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.

É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?

Azért vicces ezt így 2021 végén olvasni ... :)

Nagyon tetszett az összeomlás lefestése, ahogyan magába roskad az IPV4, mert nincs már több szabad cím. Ezt ugyan már a szövegkörnyezetből sem értettem, hogy ha az új címek elfogynak, a régiek miért nem működnek majd tovább, de így az idő távlatán át olvasni, hogy hamarosan már csak az IPV6 lesz használható, azért elég vicces. Persze, mi a hamarosan ...

Amúgy nem tudom, csak nekem van-e olyan érzésem, mintha ez egy dotált írás lett volna ...