fascinuje ma, ze uz minimalne 10 rokov citam stale dookola o bliziacej sa apokalypse sposobenej vycerpanim IPv4 adries, ktore sa urcite najneskor do dvoch rokov minu a obavam sa ze to iste budem citat este dalsich 10 rokov....
...bunker mam postaveny, zasoby nakupene a stale nic ;-)
„Aby nám stačily“ znamená, že každý dostane tak velký rozsah, o jaký si řekne – aby mohl všem svým zařízením přidělit IP adresu a zároveň mohl IP adresy strukturovat do podsítí podle své potřeby.
Že je „vyplácaná“ sedmina celého IPv4 rozsahu je hodně málo, když by dnes bylo potřeba několik rozsahů IPv4. Vždyť kompletním IPv4 rozsahem byste nepokryl ani mobilní telefony.
Chci rozsah 2^256 IP adres. Vida, mně nestačí ani IPv6. Co budeme dělat?
Vycházíte z toho, že každý jeden uživatel veřejnou statickou IP chce, což se mi nezdá.
Naprostá většina lidí nemá pro ni nemá (nejen) na mobilu využití. A může se stát, že někteří lidé (třeba já) dokonce někde dostanou veřejnou statickou IP z donucení i přestože o ni nestojí a raději by byli s dynamickou IP za NATem.
Já narážel na to, že ty IP adresy jsou nesmyslně promrhané.
Věcem co popisuješ obvykle stačí mít forwardovaných několik málo portů do vntřní sítě. Takže by stačilo, kdyby ISP dali každému klientovi pár "veřejných portů" na statické veřejné IP adrese sdílené s více uživateli, ze kterých si mohou věci forwardovat k sobě do sítě podle toho, jak si to nastaví v nějakém pěkném webovém rozhraní.
A proč by někdo měl implementovat takovou složitou logiku, která navíc bude funkční jen se dvěma, třemi transportními protokoly, kterých je jinak nejméně 20?
Co když některý ze zákazníků vygeneruje ICMP zprávu, která žádné porty nemá? Podobných problémů přináší NAT spoustu. Rozhodně to není něco, co by bylo jednoduché, funkční a neomezeně škálovatelné.
Ty protokoly tvoří naprostou většinu komunikace na internetu, stále ale existuje spousta věcí, která s nimi nevystačí.
ICMP zprávu může vygenerovat kterýkoli uzel na cestě, například z důvodu překročení velikosti MTU linky. Dané zprávy se potom týkají celé IP adresy, takže buď je NAT propouštět (a upravovat) nebude a některé věci se mohou rozbít, nebo je naopak NAT propouštět bude a tím otevírá potenciál pro DoS, kdy jeden zákazník bude odesílat ICMP zprávy, kterým znemožní komunikaci někomu jinému za stejným NATem.
Moment. Když má můj počítač s veřejnou IPv4 otevřených více TCP/IPv4 spojení s jedním serverem a několik spojení s dalšími servery a dojde mi zpráva ICMP MTU exceeded, jak poznám, ke kterému spojení se to vztahuje a co pak mám dělat? Co řešit to stejně?
Nestačilo by přehazovat v TCP/IP paketech don't fragment flag a tyhle ICMP zahodit?
Mimochodem, celý koncept MTU je při technologii přepojování paketů trochu obskurní záležitost, protože se vztahuje k vlastnostem cesty někde, kde nic jako cesta neexistuje.
Pokud problém MTU vyřeším tak, že shodím flag don't fragment, paket fragmentuji a pošlu dál, tak to fungovat nemusí, protože třeba cílový IP stack neumí skládat frgmenty dohromady. Klasicky je to třeba nějaký embedded krám s omezenými prostředky, to je velice častý případ, pokaždé nekomunikují spolu PC obludy. :-)
Uvnitř ICMP paketu je datová část, kam se vkládá začátek paketu na který se reaguje tím MTU exceeded, takže dle toho si pak můžu přiřadit, které spojení to způsobilo, pokud ta ICMP zpráva dorazí korektně zpět.
Co se týče té části packetu uvnitř ICMP packetu: teoreticky je možné se podle toho rozhodnout, prakticky to může být často neimplementované (viz.: https://blog.cloudflare.com/path-mtu-discovery-in-practice/ ), z různých důvodů (například to může být případ, kdy ten packet musí jít přes procesor místo aby šel nějakým rychlým asicem).
Já narážel na to, že ty IP adresy jsou nesmyslně promrhané.
Jenže to je úplně jedno, protože i kdyby nesmyslně promrhané nebyly, stejně by to bylo k ničemu – protože byste těch adres potřeboval řádově víc.
Věcem co popisuješ obvykle stačí mít forwardovaných několik málo portů do vntřní sítě.
K čemu je dobré řešit, které adresy a porty potřebujete forwardovat a které možná ne? K čemu je dobré, že mají stroje jiné IP adresy z vnitřku sítě a z internetu, takže to musíte obcházet v protokolech, musíte kvůli tomu kazit DNS? Pořád popisujete, že něco stačí, že je možné někde něco udělat navíc, koupit další zařízení, něco navíc analyzovat a rozmýšlet – ale jaký je přínos těchhle nákladů vynaložených navíc oproti situaci, kdybych prostě zařízení přidělil IP adresu a neřešil bych nějaké tunelování a přepisování a další nesmysly?
Vycházíte z toho, že každý jeden uživatel veřejnou statickou IP chce, což se mi nezdá.
Proč by měl chtít cokoli jiného? Cokoli jiného je jen zbytečná komplikace, která nic pozitivního nepřinese, jsou s ní spojené pouze náklady.
Statickou IP adresu sem nepleťte, to s tím nijak nesouvisí. Navíc většina chytrých mobilů je zapnutá trvale, takže ty IP adresy budou mít přidělené – tím, že se adresa přiřazené mobilu může změnit nic neušetříte.
raději by byli s dynamickou IP za NATem
Nikdo nechce být raději za NATem, protože z toho nemá žádný užitek, jenom komplikace.
Vašeho nejčernějšího scénáře bych se nebál. Nevyjde to tak strašně, jak by se mohlo zdát, jen je potřeba napsat implementaci BGP efektivněji.
Když si to jen tak od boku spočítám: velikost /32 rozsahu je 2^32. To znamená, že by si páteřní router musel držet 2^32 záznamů. Počítám, že by mu ke každému stačilo držet si čtyři bajty informace (nepředpokládám, že by to v páteři forwardovalo na více než 256^2 serverů, a řekl bych, že si BGP vystačí s dvěma bajty na uložení zbytku informací (počet hopů a třeba ještě něco dalšího).
2^32 * 4 bajty = 1024*1024*1024*4*4 = 16GB. Neboli i na vyřešení nejhoršího scénáře stačí routeru přikoupit 16GB RAM v rámci kterých bude server schopen určit, kam packet forwardovat na jeden dotaz do paměti. (protože přirozeně nebude těch 2^32 záznamů procházet sekvenčně, ale přímým skokem na správné místo v paměti.)
To mi nepřipadá tak hrozné. Po síti se ta data podle mě moc tahat nebudou, protože ty IP adresy se nepřesunují tak rychle, první start proběhne jen jedinkrát. Potom už se celá směrovací tabulka dá cacheovat na disk... Navíc mezi BGP routery jsou celkem slušné linky, takže ani přelít pár giga dat není oproti dřívější době problém atd.
Aaaa mame tu dalsi ukazku typickeho tupce kterej nema ani sajna o tom ja veci fungujou ....
Ale jo, ono ti jiste nebude vuubec ani tochu vadit, ze tvymu bgp bude trvat mesic, nez se nauci novou cestu ... ono se ji teda nenauci vubec, protoze ona se mezi tim zmeni jeste nekolikrat ... Mno a hlavne, vsici ISPci zahodej svy krabice za miliony ... a pobezej si koupit novy krabice, za desetimiliony, co natom, ze se tim nevyresi vubec nic, ale hlavne ze budou moct routovat i /32 ...
-1
Tu urážku sis mohl odpustit.
Netvrď mi tady, že se běžná IP adresa přesunuje několikrát do měsíce.
ISP nepotřebuje mít představu, jak vypadá rozdělení IP adres na celém světě. Jeho zajímá, s kým má přímý peering a s kým musí komunikovat přes páteř. To požadované množství informací velice zmenšuje. (Konkrétně na zapamatování si těch pár milionů adres, které mají lidé, se kterými má přímá spojení, což jsou řádově megabajty dat.)
Právě že pokud má konektivitu přes několik linek, potřebuje pro každou cílovou síť vědět, kam to směrovat. Tzn. mít přehled, kterou lajnou to jede nejrychlej a v reálným čase rozhodovat.
Pokud teď routuju řekněme na 200.200.150.100, vím, že platí pravidla pro 200.200/16. Před deseti minutama se někdo spojil s 200.200.150.37 a nejlíp to valí po lince #4. Můžu rovnou předat.
Když to víc fragmentuju a IPčka budou náhodně po světě, tak zjistím, že 200.200.150.100 nemá definovaný pravidlo a hledám znovu celou cestu, protože tuhle síť tenhle týden ještě nikdo nekontaktoval... Latence jak kráva a eviduju 4000M záznamů.
A ono to není o tom, že se udělá statická tabulka s číslem portu, kam to přehodit. Na úrovni BGP existují záložní trasy, každý záznam má čítač pro timeout (a ono každu ms dekrementovat čítač pro 4mld nebo 65k sítí je trochu rozdíl).
A dokážeš si představit ten režijní traffic, co se povalí páteří, aby si všichni očuchali trasy? Brrr
Ty firmy to mají rozdělený na A.B.C.D, kde to A je přidělený prefix, B je kód oblasti C je oddělení, D je konkrétní stroj (čísla nemusí mít 8b). Uvnitř se routuje transparentně:
A je naše? Zůstává uvnitř fitrmy, jinak předej ven.
B je naše? Zůstává na pobočce, jinak to hoď do příslušnýho tunelu na jinou pobočku.
C je naše? Nedělej nic (je to v LANce), jinak přepošli na router odpovídajícího oddělení.
D řeší switch.
Bylo by tak fajn, kdyby tohle šlo i v globálním netu. Mít dlouhou adresu, ke je v prefixu kontinent, země, isp, jeho zákazník, síť zákazníka a konkrétní stroj... Routování jednodušší, než teď a adresa by při tom vyšla na každou krabičku.
Jo, ale neseženeš tak velkou a rychlou paměť, co by ti to vyblila v reálným čase. V téhle kapacitě jsou jenom DDR SDRAM a ty se na toto moc nehodí.
Cyklus 1: Nastavení adresy řádku
Cyklus 2: Nastavení adresy sloupce
Cyklus 3-8 (pro rychlou CL6): čekání
Cyklus 10: Hurá, na sběrnici jsou data
Co vyhledávat, ale aspoň vymyslet, jak to číst. V rychlosti na páteři už je poznat i délka spojů menších pamětí na desce.
SRAMka v téhle kapacitě není dostupná (resp. když 1b zabere 4x větší plochu na čipu, tak by byla pekelně drahá a ještě z hodně brouků).
DRAMka má strašný režie. U grafiky nebo operační paměti podpořené cache se to dá skousnout a používat bursty, ale 16G s extrémně rychlým a opravdu náhodným přístupem je furt trochu mimo.
Ano, a ISP to stojí poměrně hodně úsilí, aby se apokalypsa co nejvíce oddálila. Je v pořádku, že jste žádné projevy nezaznamenal, protože to je cílem veškerého snažení všech těch odborníků a techniků.
Ano, ještě hezkých pár let budete podobné články číst. Ale sám nejspíš žádný problém nebudete muset řešit. Díky tomu, že se tomuto problému věnují desítky tisíc jiných lidí ;)