A hup nem érhető el IPv6-on!!444!!!44!

 ( Zozz | 2019. április 12., péntek - 20:57 )

Most vettem észre. Kinek állhat ez érdekében?

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

Itt van natív IPv6, de a hup.hu csak v4 címmel oldható fel.

Engem nem izgat, amig a hup.hu domain végén van valami...
-------------------------
Dropbox refer - mert kell a hely: https://db.tt/V3RtXWLl
neut @ présház

Hát ez az, eddig v6-on is elérhető volt.

--
Soli Deo Gloria

Sajnos, ez egy ideig így is lesz. Van egy régóta fennálló timeout probléma, amit a Rackforest próbál behatárolni. Emiatt ma este 23:00-tól új helyre (egyik szerverteremből egy másikba) költözik a szerver. Közvetlenül egy core switch-re lesz kötve, IP címet vált és egyelőre, a hibakeresés idejére a IPv6-on nem lesz elérhető.

--
trey @ gépház

Angelonak beletort a bicskaja ?
Nasty kis hiba lehet.
Feliratkozom.

+1

Köszi az infót, és hajrá a hibakergetőknek :-)

+1

--
Soli Deo Gloria

Nem csak az ipv6-tal van ott probléma.
Egyik ügyfelünknek vannak ott gépei, és a gépek közötti belső hálózat elkezdett szarakodni - mikor máskor, mint pénteken. Random packet kimaradások voltak. Négy gépen volt elvileg redundáns alkalmazás, ami emiatt olyan volt, mint a hinta... A folyamatos szakadások miatt akadozott a kiszolgálás. Átraktuk a külső lábra a cluster syncet és kommunikációt, azóta stabil. (Illetve, bekerült egy plusz gép is, de 99%, hogy nem ez oldotta meg a problémát, mert egyébként hónapok óta stabilan ment a cluster)
Szóval, vannak érdekességek a rackforestnél.
--
"Sose a gép a hülye."

Nagyon helyes.

Kis motiváció arra, hogy mindenki, akit zavar, odaforduljon végre az Internetszolgáltatójához és felszólítsa, hogy a jövőben ne az ügyfelek IPv4 címein spóroljanak a költséghatékonyság™ érdekében.

Dafuq?

Á, semmi, csak a szokásos hájblézer-féle fogalmatlam büfögés a kellemes szombati ebédje után... :-D

Na ez most hogy a ló...ban jön ide?! Merthogy most az a nagy büdös helyzet, hogy CGNAT ide, vagy oda, csak IPv4-es címre oldódik fel a hup.hu név (ez az IPv4 cím PTR-re szépen ad egy nevet, ami már IPv6 címre is feloldható), úgyhogy totál semmi köze ahhoz, hogy egy szolgáltatónak mondjuk van mondjuk összesen egy /16-nyi címtartománya, miközben van százezres nagyságrendben ügyfele, akinek IP-t kéne adni, ami picit utánaszámolva nem igazán megoldható CGNAT nélkül.

Ja, és ez nem költséghatékonyság miatt van, hanem azért, mert explicit nincs elég kiosztható, publikus, route-olható IPv4-es címtartomány. Bár tudom, hogy téged a tények, mint olyanok soha nem zavartak.

A cél/ok jelen esetben az, hogy IPv4-en forgalmazva egyszerűbb lehet egy hálózati forgalomban adódó hibát levadászni. Nem, nem mindegy, hogy dual stack vagy sem - szerintem aki a túloldalon ezzel foglalkozik, sokkal jobban tudja, hogy mit csinál és miért.

Idézet:
Na ez most hogy a ló...ban jön ide?!

Úgy, hogy a végeredmény az, hogy a HUP nem elérhető IPv6-on keresztül. Néhány internetszolgáltató nagyon szereti mostanában az előfizetőit a tudtuk és külön beleegyezésük nélkül IPv6-only hálózatra tenni, csakmert ott végtelen™ cím áll rendelkezésre és így multiéknak is költséghatékonyabb™. Kevesebb IPv4 cím ugye többe kerül, mert kevesebb van belőle. Ezeknek az ügyfeleknek a HUP nem fog bejönni. Tehát, nekiállhatnak reklamálni multiéknál, hogy tegyék őket normális (IPv4) hálózatra. Amit szerintem jól is tesznek, mert tisztességtelen magatartásnak tartom az átrakosgatást. Erről szólt a kommentem. Nem A CGNAT-ról, nem a PTR rekordokról. Persze, elhisszük, hogy te ezekben is expert™ vagy.

"Néhány internetszolgáltató nagyon szereti mostanában az előfizetőit a tudtuk és külön beleegyezésük nélkül IPv6-only hálózatra tenni" - na egyet mutass lécci...

UPC előszeretettel frissítgetett szoftvert az elmúlt 2 évben a modemjein, melyek utána már csak IPv6 címet voltak hajlandóak kiosztani. A visszaállításra csak ügyfélszolgálattal való levelezgetés, telefonálgatás útján kerülhetett sor.

Na ezt mégegyszer... Tehát azt állítod, hogya z UPC ügyfelek kizárólag IPv6-on mentek ki a nagyvilág felé, kizárólag az IPv6-os címekkel rendelkező kiszolgálókat látták?
Vagy egyszerűen az IPv6 bekapcsolása után (a DS-Lite okán) nálad kliens oldalon nem működött minden ugyanúgy, mint azelőtt, és nem sikerült megoldanod, csak az IPv6 kikapcsoltatásával?

Volt mindkettő esetből bőven.

Tehát az "és nem sikerült megoldanod, csak az IPv6 kikapcsoltatásával" esetből is volt bőven?
Végre egyszer elismered, hogy van valami, amihez többször sem sikerült értő módon hozzányúlnod... Mondjuk UPC-s ismerőseimnek (szakmabelieknek és attól messze távol állóknak egyaránt) nem volt ilyen jellegű problémájuk... Lehet, hogy mégsem az UPC a hülye...?

Nálam nem volt ilyen probléma, csak jelzem. Nem tudom, ezt hol olvastad ki a hozzászólásomból. De látom most sem az alapproblémát akarod megérteni, csak az én véleményemet akarod a földbe taposni, eljelentékteleníteni. Pörgesd vissza szépen a UPC Magyarország Facebook oldalát 2017-2018-as években és olvasgasd a megszámlálhatatlan panaszt az IPv6-only címekről.

Idézet:
Mondjuk UPC-s ismerőseimnek (szakmabelieknek és attól messze távol állóknak egyaránt) nem volt ilyen jellegű problémájuk

Az én UPC-s ismerőseimnek meg képzeld el, hogy voltak. Az pedig nem a felhasználók sara, hogy a UPC a beleegyezésük nélkül egy másik IP protokoll réteget húz fel a saját önző érdekében, ráadásul úgy, hogy az oldalak fele nem jön be IPv6-on.

Az UPC nem hülye, hanem szimplán egy arrogáns multi. Emellett még szélsőségesen idealista is, amikor azt hiszi, hogy az 1001 féle módon konfigurált rendszereken majd mind automatikusan fog működni az új baromsága, amit a felhasználókra akar erőltetni.

"Nálam nem volt ilyen probléma, csak jelzem. Nem tudom, ezt hol olvastad ki a hozzászólásomból."

Hogy hol? Ezt írtam:

"Vagy egyszerűen az IPv6 bekapcsolása után (a DS-Lite okán) nálad kliens oldalon nem működött minden ugyanúgy, mint azelőtt, és nem sikerült megoldanod, csak az IPv6 kikapcsoltatásával?"

Mire azt válaszoltad, hogy:

"Volt mindkettő esetből bőven."

"automatikusan fog működni az új baromsága, amit a felhasználókra akar erőltetni" - Nem az UPC baromsága, DS-Lite van, ha jól tévedek, annyi történik, hogy az IPv4 NAT mögé kerül emiatt. Kliens oldalon dual stack és DHCP a megoldás, ahol saját gányoltan beállított router vagy épp fix ip-k voltak a LAN oldalon, ott valóban lehetnek problémák, de minthogy nem ez a normál/általánosan javasolt felállás, hanem az, hogy DHCP mindenkinek a kliens oldalon.

Nekem a Digi adja a netet, simán dual stack megy minden eszköz, anno FTTH okán kapott dobozt a telepítéskor átrakattam bridge módba, úgyhogy nincs dupla nat (ahol ugye jól kell megválasztani a LAN-oldali címeket, hogy ne ütközzön a szolgáltatói eszköz által az üf. oldal felé osztot címekkel), nincs problem.

Amilyen problémás esetekről eddig tudomásom volt, azoknál egytől egyig számítógép modemre kötve, DHCP-n címet kérve volt a felállás. A gond pedig vagy az volt, hogy IPv4 címet szimplán nem kapott (NAT-oltat se!), vagy az, hogy DNS feloldás után beleakadt az IPv6-os címbe a böngésző, ami elérhetetlen volt (nem tudni, miért), és bár v4-en volt elérés, azt nem használta. Lényeg, ami lényeg: A UPC egy ki nem próbált, sok szempontból defektes megoldást nyomott le az előfizetők torkán, azok beleegyezése nélkül. Ezt úgy hívják: arrogáns, felelőtlen viselkedés. Szóval, felőlem nyugodtan védheted multiékat. Az én véleményem nem fog változni a UPC-ről. Őszintén szólva pedig nem is érdekel, mert nekem is Digim van. :)

Érdekes, de ilyen problémáról tömegesen nem szólnak se a publikus hírek, se más információforrások, úgyhogy nekem még most is a kliens-oldal tűnik "sárosnak", még akkor is, ha te ex cathedra kijelented, hogy az "UPC egy ki nem próbált, sok szempontból defektes megoldást nyomott le az előfizetők torkán". A DS-Lite működő megoldás, csak tudni kell használni.

Félreérted, nem a DS-Lite-ra gondolt, mint nem kipróbált, hanem az IPv6-ra. Mert bezzeg az IPv4-nek már van 38 évnyi kipróbálása és egyébként is elsőre tökéletesen működött, soha nem kellett hozzányúlni (jó, 92-t, 98-at és 2013-at most hagyjuk), azt csak olyan technológiára lehet lecserélni, amivel legalább ennyi évnyi aktív szakmai tapasztalat van. Mondjuk a 1149-re, amiből az RFC ugyan későbbi, de a technológia korábbi.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

+1 :-D

Te érted félre. A hangsúly azon volt, hogy nem fizető ügyfeleken kéne kísérletezni.

Az IPv6 kipróbált, működő technológia, ahogy a DS-Lite is. Az, hogy az ügyfelek elenyésző részénél problémát okoz (döntően az ügyfél oldali eszköz hibás és/vagy nem a szolgáltatói ajánlás szerinti beállítása miatt, az minden technológiaváltásnál létező dolog, de ettől még nem kell habzó szájjal okádni a szolgáltatóra. Igen, másképp működik, kell neki a korrekten működő PMTU discovery, kell olyan OS, ami jól működik DS-Lite környezetben (tehát nem valami 1024 éves ősmaradvány), ha saját router van, akkor vagy azt kell bridge módba rakni, vagy azon kell jól megcsinálni a NAT-ot (belső hálóra nem a szolgáltatói eszköz által használt tartományt/tartományból osztani címet), és hasonlók. Vagy, ha balf@sz az ezzel foglalkozó "szagember", akkor kikapcsoltatni az IPv6-ot, mert az megoldja, pontosabban megkerüli a problémát.

Egyébként az 1001-féle (részleteit tekintve lehet akáűr sokkal több, bár néhány nagyobb halmazba simán besorolhatók, amikre vannak is tesztek) módon konfigurált ügyfél oldali cuccokra hogyan tesztelnél szolgáltatói oldalon, he?

Nem azért okádok habzó szájjal a szolgáltatóra, mert technológiát váltott. Azért okádok habzó szájjal, ahogy ezt megtette. A UPC szélsőségesen idealista, sunyi módon vezette be az IPv6-ot, azt feltételezve, hogy mindenkinél egyből működni fog, hiszen a vindózhét, a vindóznyóc, a vindóztíz (meg még az XP) is támogatja. Néhány apróságról azonban elfeledkeztek és lett is belőle bőven baj.

Ha mindenáron az előfizetőkön kell tesztelni, akkor tessék szíves lenni a milliárdos költségvetésből kifáradni ahhoz az 1001 emberhez egy pilot projektben, szemrevételezni a valós konfigurációkat, és feltárni az esetleges buktatókat. Arról nyilván van fogalmuk, milyen rendszereket használnak milyen felállásban. Egy simpla MAC címből ki lehet deríteni a csatlakoztatott eszközök típusát, abból pedig lehet következtetni, hogy az mire képes. A nem mindennapinak tűnő konfigurációkat listába lehet venni és meg lehet tekinteni személyesen.

Ha 1001 emberről van szó, akkor teljes nyugalommal lesz@rja a szolgáltató, mivel kerekítési hibának is kevés a számosságuk - majd panaszkodnak, és egyedileg kezelik a problémájukat, ha szükséges.

A MAC csak az első eszköznél látszik, ha routert hasnzál a delikvens, de nagyjából semmit sem jelent, hiszen csak egy gyártót lehet behatárolni, azt, aki a hálózati adapter L2-jét adó hardverét csinálta. Hogy mögötte mi van L3-on és fölötte, arról egy bitnyi infót nem ad. Ha meg a szolgáltató elkezdene fingerprintinget csinálni az üf.-ek eszközeire, hogy ki, mit hasnzál, akkor szerintem te lennél a legjobban felháborodva, hogy hogy képzelik ezt, semmi közük hozzá, ésatöbbi.

Pilot volt/van minden jelentősebb bevezetés, technikai váltás előtt - az ismert, nagyobb halmazokra tesztelnek, ahogy írtam is, de mindenre maximum elvileg lehet tesztelni. Egyébiránt a szolgáltató az eszközének az Ethernet portjáig felel a beállításokért, azon túl az üf. dolga és költsége. Mint ahogy pl. a gázszolgáltató sem fog neked kazános szakembert adni, hogy beállítsa a berendezésedet - ad egy szabványos szolgáltatást, elvár(!) egy szabványos berendezést, amit megfelelően feljogosított szakemberrel kell beállíttatnod/beköttetned, és kész, működik a dolog.
De a kábeltévés cégek sem küldtek/küldenek tévé-hangoló embereket az ügyfelekhez akkor, amikor az analóg csatornák helyett a DVB-C lett/lesz az elsődleges szolgáltatási "felület" - ha megoldod magadnak, akkor tudod használni (nézni) a teljes szolgáltatáshalmazt, ha nem, és csak analógon vagy képes beállítani a csatornákat, akkor így jártál. Legfeljebb kérsz segítséget az ügyfélszolgálattól, akik vagy telefonon, vagy fizetős kiszállás keretében megpróbálnak segíteni a bajodon.

> Egy simpla MAC címből ki lehet deríteni a csatlakoztatott eszközök típusát, abból pedig lehet következtetni, hogy az mire képes.

Akkor kezdjük az elején.

52:54:00:2b:fe:58

Kérlek, mondj el mindent erről a MAC címről. Ebből az egy darab MAC-címből mondj el mindent a csatlakoztatott eszközeim (többesszám, bazmeg!!!!!) típusáról. Eleve hányan vannak?

Csak hogy segítsek: érdekelne, hogy ki a hálózati kártya gyártója; az a kártya milyen gyártó gépében van; az a gép laptop, asztali gép, vagy épp hálózati nyomtató esetleg router vagy más; ha (tételezzük fel: általános célú OS fut rajta, akkor) milyen gyártmányú ez az OS; tud-e ez az OS DECnet-et, IBM SNA-t, IPX/SPX-et, TCP/IP-t, ezen belül IPv4-et, IPNG-t, IPv6-ot - dual-stackban is, vagy csak egyiket, másikat. És í. t.

Könnyítés, csak hogy jó irányba kezdj el gondolkodni. Nem, ezek legnagyobb részét ez alapján nem tudod megmondani. Ugyanis a MAC-cím összesen egy gyártót határoz meg, aki *jó* *esetben* gyárttatta azt a szerencsétlen hálózati kártyát (ráadásul ahogy zeller írta is: a szolgáltatóig el sem jut). A MAC-cím sok esetben módosítható. Sok esetben módosítják is. Hamisítható - sok esetben hamisítják is (*)

Ha véletlenül valami apróságot elírtál volna itt fenn és én valamit félreértek ebben a félreérthetetlen észosztásban: elárulnád, hogy mire képes hálózati szinten egy Windows (melyik verzió, melyik SP, melyik patch), egy Linux (milyen kiadás, melyik kernelverzió, milyen patchek), egy BSD (melyik BSD, milyen kiadás, stb.) FreeBSD-ben 3-féle csomagszűrő tölthető be egymás mellé (technikailag inkább egymás mögé), ezek midegyike *másként* NAT-ol. Meg tudnád mondani, hogy fenti MAC cím ezek közül melyikre jellemző?

A fenti eszmefuttatás még sokáig folytatható, de inkább összefoglalom egy kérdésben: nem lehet, hogy te, aki itt folyton-folyvást másokat (embert, céget, elvet) próbálsz ködös tévképzetek alapján leszólni; te, aki negatív kifejezésként próbálod eladni a "mérnök" kifejezést; szóval nem lehet, hogy Jókaihoz mérhető hosszúságú regényeid két főalakja közül te vagy az egyik? A mérnök nem lehetsz, mert láthatóan gondolkodni nem szoktál, és tudásod sincs - legalábbis az eddigi témakörökben nem volt.

Így viszont marad a sokat emlegetett Tapicskoló Tamás. A hozzáértés nélkül mindenbe belebüfögő, mindent mindenkinél jobban tudó übermensch.

Nem használok trollszűrőt, de valahányszor belédfutok, minden alkalommal az jut eszembe, hogy nagyon kéne.

(*) rá kéne nézned egy modern (mondjuk az utóbbi 15 évben gyártott) SOHO-router beállítófelületére, ahol jellemzően be lehet állítani, hogy akarsz-e MAC-cím hamisítást a szolgáltatói (WAN) oldalon.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Nem, te nem érted. Mind az IPv6 mind a DS-Lite sok éves technológiák (21 és 8), rengeteg real-world bevezetéssel, amelyeknek a tapasztalatai mind kellettek - az IPv6 _tavaly_ kapta meg az Internet Standard státuszt (RFC 1883: 1995, RFC 2460: 1998, RFC 8200: 2017 - ez utóbbi kapta meg az Internet Standard minősítést). Ez pontosan ugyanaz az evolúciós folyamat, amit az IPv4-nél is meg kellett csinálni (RFC 791: 1981, RFC 1394: 1992, RFC 2474: 1998, RFC 6884: 2013), csak azzal néhány nagyságrenddel kevesebben találkoztak egyszerűen az internet-hozzáférés elterjedtsége (ill. annak hiánya) miatt.

Nem tudom, mióta van net hozzáférésed. Én még emlékszem azokra az időkra, amikor W98-hoz driver discről kellett PPPoE drivert telepítgetni, hogy csatlakozni tudj a nethez - a szolgáltató adott mindenkinek lépésről lépésre screenshotokkal teli leírást (az ismerettségi körben meg mindenki engem keresett vele). Akkor a szemét szolgáltató, miért kényszeríti a felhasználókat a rendszer módosítására, mit flancol itt a PPPoE-vel, ami ennyire új dolog?

Igen, előfordul, hogy módosítanod kell a rendszeren külső dolog miatt. Általában ez azért van, mert nem szokásos konfigurációt használsz (esetedben: IPv6-ot nem teljesen támogató operációs rendszer, a fenti PPPoE-nél pedig a technológiát alapból egyáltalán nem támogató operációs rendszer), minden HW/SW kombinációval pedig nem elvárható a szolgáltatótól, hogy teszteljen.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Akármennyire is magyarázod túl a dolgot multiékat mosdatandó, továbbra is arról van szó, hogy az arrogáns UPC egy szoftverfrissítéssel lehetetlenítette el azt, ami előtte évekig jól működött. Ócska kifogás az ügyfélre mutogatni, pláne akkor, ha manapság a végletekig butított kezelőfelületű szoftverekben még azt sem lehet értelmes módon beállítani, hogy egyes oldalakat csak IPv4-en próbáljon meg elérni a böngésző.

Akarmennyire is magyarazod tul, az internet szolgaltato a sajat vegeszkozeig felelos barmiert.
Az, hogy mogotte a kedves juzer mit taknyol es a taknyolasbol adodoan miert "nem mukodik a Zinternet", az user error, nem tobb, nem kevesebb.
Ha kozvetlen radugod a gepedet, DHCP-t bekapcsolod es mukodik, akkor mukodik. Az otthoni szetbarmolt halozat megjavitasa _nem_ a szolgaltato feladata. Persze van olyan is amelyik _jo_penzert_ bevallalja neked.

Itt épp arról van szó, hogy rádugod a gépedet, DHCP-t bekapcsolod és nem működik.

Minden további nélkül lehet ilyen probléma, szolgáltatói oldal logot néz, modemet resetel, egyedileg kezeli a hibát. Ugyanis nem tömeges hibákra deploy tervezése/elvégzése során nem kell "lőni" - nem éri meg előre az 1001 plusz esetet kitlálni, hogy micsoda, végigtesztelni, miközben nagyságrendekkel nagyobb felhasnzálói körnek nem okoz gondot.
Nálam is volt PPPoE döglés a Digi-vel kapcsolatban, log szerint kiment a kérés, a túloldal szerint nem érkezett meg, lognézegetés mindkét oldalon, dump, aztán kiderült, hogy a pppd rohadt le úgy, hogy hibás csomagot toltt ki magából. Ettől még nem esek neki a Diginek habzó szájjal, hogy sz@r spúr banda, ahogy azért sem, mert szó nélkül beraktak anno CGNAT mögé, amit egy telefon volt visszacsináltatni. Mivel az ügyfelek jelentős részének nem probléma, viszont a CGNAT-tal a korlátos és nem növelhető erőforrás (IPv4 címek) használatban maradhat, bőven vállalható az, hogy akinek kell, azt kiveszik a CGNAT mögül.
Ugyanígy akinek "fáj" a DS-Lite meg az IPv6 UPC ügyfélként, az szól, és visszarakják v4-only konfigra.
Azt kell felfognod, hogy szolgáltatóként nem az egyedi igényekre, hanem az ügyfelek nagy hányadának való megfelelésre kell gyúrni - az egyedi igényeket meg lehet üfsz.-on, egyéni esetként kezelni.

És az "arrogáns UPC"-től elvárod, hogy mondjuk out-of-the-box MS-DOS-szal kapj netet "bedugom oszt megy" alapon? Akkor a _pontosan_ ugyanilyen kategóriás (EOL, unsupported) Windows XP-dnél miért várod el?

A szolgáltatónak _semmi_ köze a te eszközödhöz, max segíthet beállítani (ahogy pl. a T-nek van egy doksija az IPv6-ről, amiben sorolják az XP IPv6 bugjait és a működő workaround-okat: https://www.telekom.hu/static-tr/sw/file/IPv6_user_guide6.pdf)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Azt várom el, hogy a hálózati szabványoknak megfelelően kapjak Internetszolgáltatást, mindenféle idealista gányolás nélkül. Tehát, ha a UPC azt állítja, hogy UTP kábelen szolgáltat IPv4 hálózatot, akkor elvárom, hogy működjön és ennek semmi köze nincs ahhoz, hogy a Microsoft támogatja-e az XP-t vagy sem. Az XP-hez van hálózatikártya driver és IPv4-et is támogat, tehát működnie kell. Amennyiben nem működik, akkor elvárom a UPC-től, hogy javítsa ki a hibát, akkor is, ha az operációs rendszer nem támogatott. Pláne, ha tegnap még gond nélkül működött.

Idézet:
hogy mondjuk out-of-the-box MS-DOS-szal kapj netet "bedugom oszt megy" alapon?

Továbbra is csak azt várom el, hogy ha egyszer megcsináltam, hogy működjön (akár MS-DOS alatt), akkor ne változtatgassanak egyoldalúan, a tudtom és beleegyezésem nélkül hálózati konfigurációt, a saját önző érdekükben (pl. mert drága nekik az IPv4 cím a multimilliárdos költségvetésük mellett).

"ha egyszer megcsináltam, hogy működjön (akár MS-DOS alatt), akkor ne változtatgassanak egyoldalúan, a tudtom és beleegyezésem nélkül hálózati konfigurációt" - csaxólok, hogy olvasni kéne tudni,pl. ÁSzF-et, illetve szolgáltatói közleményeket -e zekben ugyanis számodra meglepő dolgokat találhatnál a szolgáltatás technikai-technológiai paramétereiről, feltételeiről (milyen eszköz/szoftver/protokoll támogatott és mi az, ami nem), SLA-ról, valamint arról, hogy milyen változások várhatóak és mikor.

"mert drága nekik az IPv4 cím" - Nem drága, te nagyon gyagya, hanem mert NINCS több. Nincs, nem lehet venni, vége, elfogyott. Maximum CGNAT mögé lapátolva, de az meg más miatt fog téged szájhabzásra ingerelni.

Anno MS-DOS alatt modemes-behívós-BBS-es megoldások voltak, meg volt FidoNET, illetve volt valami FTP Software nevű cégnek PC/TCP csomagja, amivel DOS_ból is ment az IP-hálózat, ha a kártyához volt megfelelő packet driver - igaz, az IPv6-ot nem fog tudni, dula stack-et meg pláne nem, és tán DHCP-re sem képes :-P

Aha és ha az ÁSZF-ben leírják, hogy csak Windows 10-et támogatnak, akkor az úgy szerinted korrekt™, etikus™ és elfogadható™. Mert szokás szerint megint multiékat véded, csak az ő érdeküket vagy képes meglátni és a jogászkodással túlterhelt ÁSZF-et tekinted szentírásnak.

Amíg LAN kábelen kapom az Internetet és az egyik nap működik Windows XP-ről, akkor a szolgáltatónak kutya kötelessége garantálnia, hogy az másnap is működjön. Az égvilágon semmi köze nincs hozzá, hogy milyen operációs rendszert használok és nem kötheti ki nekem.

Idézet:
Nem drága, te nagyon gyagya, hanem mert NINCS több.

De van. Ott van cloud-multiéknál egy csomó. El lehetne tőlük kérni, meg lehetne vásárolni. Persze, nem elég a Facebooknak, a Googlenak, Spotifynak, meg az N+1. idealista startup ökröknek egy-egy IP cím, ahová bepakolnak nagysebességű szervereket. Nekik hatvanötezer szerver, meg CDN, meg fiszem-faszom kell. (Külön megkérlek, hogy ne kezdj el papolni a terlehléselosztásról, mert nem érdekel). Emellett, Tapicskoló Tamás egységsugarú birkának bőven elég a NAT-olt cím is. Mivel erre szolgáltatóék nem jöttek rá időben, így elpocsékolták a maradék IPv4 címet.

Egyrészt a szolgáltató sem hülye, nem fog olyan követelményeket támasztani a klienseivel szemben ami jelentős hányaduknak problémát okoz. Másrészt a szerződés megkötésekor nyilatkoztál arról, hogy megismerted és elfogadod az ÁSZF-et, ha valami nem tetszik át lehet menni másik szolgáltatóhoz. ÁSZF módosításkor pedig általában lehetőség van szerződés bontásra, pl. idézet a DIGI ÁSZF-éből:

Idézet:
12.2.3 Az Előfizetőt az ÁSZF egyoldalú módosítása esetén megillető jogok

Amennyiben a módosítás az Előfizetőszámára bármilyenhátrányos rendelkezéseket tartalmaz-így különösen, ha a szolgáltatás díja emelkedik, módosul a kínált csatornák összetétele vagy a szolgáltatás tartalma -,az Előfizető az értesítéstől számított 45 napon belül, azonnali hatállyal, további jogkövetkezmények nélkül jogosult felmondani a határozott időtartamú Előfizetői Szerződést.

"Amíg LAN kábelen kapom az Internetet és az egyik nap működik Windows XP-ről, akkor a szolgáltatónak kutya kötelessége garantálnia, hogy az másnap is működjön."

Ilyen alapon mai napig lenne 1. generációs GSM szolgáltatás a 450 MHz-es tartományban meg lenne analóg földfelszíni TV sugárzás, mert "tegnap még működött".

"Amíg LAN kábelen kapom az Internetet és az egyik nap működik Windows XP-ről, akkor a szolgáltatónak kutya kötelessége garantálnia, hogy az másnap is működjön." Nem. A szolgáltatónak azt kell garantálnia, amit az általad is megismert és elfogadott ÁSzF-ben vállalt, annál egy negyed bittel sem többet. Az ügyfél-szolgáltató jogviszonyban izony elsődlegesen az ÁSZF a "szentírás", kivéve, ha bíróság máskép nem rendeli. Ha a szolgáltatóü ma azt mondja, hogy 30/60/90 nap múlva nincs IPv4-only hozzáférés, csak dual stack, akkor te két dolgot tehetsz: kireszeld a helyi motyókat, hogy ne rottyantsanak maguk alá a dual-stack felállástól, vagy mindenféle külön költség nélkül felmondhatod a szerződést.

A FB meg a Google, ahol lehet IPv6-on megy, úgyhogy ők csak az ódivatúak miatt szivatják magukat is az IPv4 megtartásával. Attól, hogy téged nem érdekel, hogy hogyan és miért van/kell CDN, meg hasonló terheléselosztás, illetve replikációs és egyéb, world-wide szolgáltatások alá kitalált infrastruktúra, attól még egyrészt kell, másrészt van, pont azért, hogy azzal, ami drága (hálózati sávszélesség) azzal takarékosabban lehessen bánni.

Az átlagos felhasználásra valóban megfelel, ha CGNAT mögül érik el a szolgáltatójuk hálózatán kívüli világot, ez pont azért került bevezetésre, hogy akiknek nem elég ez a felállás, annak jusson publikus IPv4-es cím, ha nagyon kell.

Idézet:
akkor ne változtatgassanak egyoldalúan

Idézet:
ennek semmi köze nincs ahhoz, hogy a Microsoft támogatja-e az XP-t vagy sem.

Idézet:
Amennyiben nem működik, akkor elvárom a UPC-től, hogy javítsa ki a hibát, akkor is, ha az operációs rendszer nem támogatott.

Ne változtatgassanak egyoldalúan, de javítsák ki a hibát, mert a _te_ nem támogatott OS-ed _te_ általad készített konfigurációjával nem működött valami és ezért _ők a hibásak_.

Idézet:
hálózati szabványoknak megfelelően kapjak Internetszolgáltatást

https://tools.ietf.org/html/rfc6333
Tessék, ennek a hálózati szabványnak megfelelően kapsz Internetszolgáltatást.

Egyébként meg, kérlek, definiáld már, hogy Te, mit értesz Internetszolgáltatás alatt? Melyiktől melyik rétegig "javítsa meg" a szolgáltató, ha valami nem megy?
A szolgáltató felelőssége, hogy az Ethernet-kábel, ami megy a gépedbe megfelel-e a két oldalon levő portoknak?
A szolgáltató felelőssége, ha mondjuk az eszközöd nem támogatja az Auto MDI-X-et, és a link nem jön létre?
A fenti PPPoE-s példánál: a szolgáltató felelőssége, hogy a PPPoE menjen az eszközödön?
A szolgáltató felelőssége, ha te beállítasz egy fix IP-t a gépeden messze azon a tartományon kívül, amit a szolgáltatói eszköztől DHCP-n kapnál?
A szolgáltató felelőssége, ha te fogalmatlanul eldobatod a saját routereddel az ICMP csomagokat?
A szolgáltató felelőssége, ha te a helyi hálódra rossz MTU-t állítasz be?
A szolgáltató felelőssége, ha te beállítod az OpenDNS-t DNS szervernek a végpontjaidon és le van dögölve az OpenDNS (vagy CloudFlare DNS, Google DNS, akármi, ami _nem_ a szolgáltatóé)?
A szolgáltató felelőssége, ha debugolják a hup.hu-t ezért a TCP/443 elhajt a francba?
...

Komolyan kérdezem: _melyik_ az a szint, ami még "az oldja meg a szolgáltató" és melyik a felette levő _szerinted_? A fentiek mindegyikével találkoztam már élőben, egyik sem a szolgáltató hibája volt.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

"pl. mert drága nekik az IPv4 cím a multimilliárdos költségvetésük mellett"

Ha még csak ez lenne a gond...

/8-ak már elfogytak teljesen (IANA=full üres), szóval nem lehet már semmit kiosztani. A RIPE is hivatalosan 4,6 millió ip címmel gazdálkodhat (/10-es blokktól egy kicsit több ip). Ez oszlik meg a teljes kontinentális európában. Saját használatra ebből megtartanak egy keveset és a többit vehetik meg az európai netszolgáltatók.

Idézet a RIPE oldaláról:

"You need to be a member of the RIPE NCC (an LIR) in order to receive IPv4 address space. As we are now allocating from our last /8 block of IPv4 address space, you can request one final /22 IPv4 allocation (1,024 addresses). LIRs can assign this address space to End Users and to their own network infrastructure. No new IPv4 Provider Independent (PI) space will be assigned."

Ez röviden annyit jelent, hogy ASN-enként a RIPE tagok 1024 publikus ip címet vehetnek még összesen. Gondolhatod, hogy a UPC-nek ez kb molylepke fing mennyiség és valószínűleg már régen megvette, de még a helyi Pistike WIFI-t szór Bt-nek sem nagy mennyiség.

Szóval előbb tájékozódj egy kicsit.


Vizsgára felkészülés végett keresek "kidobásra" szánt menedzselhető Cisco switch-eket és routereket, leginkább Pest és Bács-Kiskun megye területén.

sokat varsz tole. gondolkodni sem kepes troll, nulla tudassal.

Pár dolgot azért tegyünk tisztába,
- az IANA-nal valóban elfogytak a szabad tartományok bár a 240.0.0.0/4 eléggé el van/lett balfaszoskodva, illetve elő-elő kerül egy-egy subnet még
pl.: https://www.ripe.net/publications/news/announcements/ripe-ncc-receives-23-from-ianas-recovered-pool

- ettől függetlenül vásárolni lehet címet, vannak tartományok amiket meg lehet vásárolni, persze jó pénzért (~15eur/IP), hiszen a kiosztott
címek szabadon cserélhetnek gazdát, mint a használt autó
több RIR között már jól bejáratott kereszt megállapodások vannak a RIR-ek közötti mozgatásra

- a RIR-eknél is vannak még szabad tartományok és forognak is vissza a pool-ba (megszűnt LIR-ek miatt pl), persze lassan

- a 4,7 m ip a RIPE-nal kiosztható, a fenntartott és a karanténban levő poolok plusz 0.7m

- a RIPE-tól nem tudsz venni tartományt, a RIPE-nál tag lehetsz és minden tagnak jár egy /22, nem ASN-enként hanem LIR tagságonként,
LIR tag nem csak a UPC és a Pistike Bt. lehet hanem Pistike is és nem csak egyszer

Szóval IPv4 címet szerezni nem lehetetlen, érdemes nézni időről időre, hogy a nagy "felhő" szolgáltatók prefix listája, hogyan bővülget (aws,azure,gce,ovh stb). Sosem látott (hirdetett) legacy tartományok kerülnek elő.

Persze ettől még nyilván szarabb a helyzet mint pl. 10 éve volt, érdekes lesz nézni meddig fújják fel a lufit az IP árakkal és mikor pukkad ki.

Így valóban pontosabb.

A lényegen viszont nem váloztat, hogy nagyobb tartományhoz már a varázssüvegbe kell egy kicsit nyúlni és nem elég csak a lóvét villogtatni, mint 10-15 éve.


Vizsgára felkészülés végett keresek "kidobásra" szánt menedzselhető Cisco switch-eket és routereket, leginkább Pest és Bács-Kiskun megye területén.

De jó messze jutottál az ipv6 only szolgáltatótól szóló épületes baromságtól...