Vlákno názorů k článku Stav IPv4: drancování a všudypřítomný NAT od hugogohu - Zase jeden debilní propagandistický článek. Kdyby IPv6 nebyla překombinovaná...
-
hugogohu (neregistrovaný)
Zase jeden debilní propagandistický článek.
Kdyby IPv6 nebyla překombinovaná sračka, už dávno IPv4 nahradila. Jenomže bohužel se vývoj IPv6 raději řídil dementní ideologií („NAT je zlo, musíme udělat všechno proti tomu, aby v IPv6 byl NAT možný“, atd., atd.), takže ve svém důsledku vznikl paskvil...
-
NAT vznikl a existuje jen proto, že není dostatek adres pro všechna zařízení. IPv6 má adres dost, takže jediný důvod pro NAT padl. Proč bych ho měl chtít v síti mít? Jen by mi komplikoval život a dělal úzké hrdlo.
A v čem je IPv6 překomplikovaný? Já mám pocit, že tyhle věci opakují jako mantru lidé, kteří si na šestku nikdy nesáhli. Někde to zahlédli na nějakém fóru, tak to musí být pravda.
-
bflmpsvz (neregistrovaný)
> NAT vznikl a existuje jen proto, že není dostatek adres pro všechna zařízení.
Jo, tak Vám ten mozek pěkně vymyli. Samozřejmě, že s takovýmto _straw_man_ je jednoduché všem vnucovat, jak že je to IPv6 nenahraditelné.
Skutečnost je ale totálně odlišná. NAT (lépe řečeno maškaráda) vznikl(a) a existuje proto, aby se stroje v určité síti tvářili jako jeden stroj. A to může mít 1000+1 důvodů. Tak se probuďte a přestaňte být tak ideologicky zabedněný!
-
jouda (neregistrovaný)
Třeba když chci mít pod jedním DNS názvem víc služeb, které dělá obecně víc backendů, jak to udělám bez NATu?
(však load ballancing není nic jiného než generalizace NATu)Protože obecně to, že servery které nejsou internet facing nejsou routovatelné z internetu přináší další ochranu (možná se budeme lišit v hodnocení jak velkou)? (když se někdo někde uklikne a povolí omylem Any-Any, tak se v případě maškarádované sítě nic neděje, sice "NAT není firewall", ale on ten paket skončí v reálnějším scénáři na CE routeru, kterej ho stejně pošle defaultou zase ven, zatímco u plně routované sítě je malér okamžitě)
-
Filip JirsákStříbrný podporovatelDíte pod jeden DNS název víc IP adres. Na rozdíl od řešení s NATem tam pak nebudete mít single point of failure. Je pozoruhodné, že NAT obhajují lidé, kteří neznají ani základní věci.
To, že nějaký server není routovatelný z internetu není vlastnost NATu, naopak NAT se používá pro řešení tohohle problému. A to, že to zařízení není routovatelné z internetu je často jen ničím neopodstatněná domněnka.
když se někdo někde uklikne a povolí omylem Any-Any, tak se v případě maškarádované sítě nic neděje
Ale děje. Navíc pokud se někdo takhle uklikává, nezachrání ho ani fyzické odpojení počítače od sítě…on ten paket skončí v reálnějším scénáři na CE routeru
A nebo skončí na cílovém počítači, protože útočník předem z kompromitovaného počítače ve vnitřní síti udělal tu správnou díru do NATu. -
Filip JirsákStříbrný podporovatel
Ne, do DNS dáte pod jedno jméno třeba 3 IP adresy web serveru, pro doménu tam dáte třeba 5 adres SMTP serverů (tam dokonce můžete určit i priority), no a pod jméno souborového serveru tam nejspíš dáte jenom jednu IP adresu.
-
Filip JirsákStříbrný podporovatel
Vždyť jsem vám to psal. Chcete víc backendů – máte třeba 10 Apache serverů, na kterých běží nějaká aplikace. Když máte backend, budete chtít asi nějaký frontend, nejspíš na rozvažování zátěže. Z pohledu uživatele je to jeden frontend s jedním DNS názvem, vy chcete, aby to bylo více služeb, asi na různých zařízeních s různou IP adresou. Tak do DNS pod ten název dáte několik A a AAAA záznamů. Pokud by se jednalo o e-mail, dáte tam několik MX záznamů, pokud třeba o Jabber, bude tam několik SRV záznamů…
-
Ja som to pochopil tak, ze sa snazi dosiahnut nieco taketo: http://www.ideaz.sk/~bwpow/47/scr/loadbalancer.png
Ma proste nejaku mnozinu serverov, pricom na tych serveroch bezia rozne sluzby. Ma pred nimi router, ktory je dostupny pod domenovym nazvom a konkretnou IPv4/IPv6 a mal by robit load balancing tym sposobom, ze by na zaklade protokolu a portu presmeroval packet na jeden zo serverov, ktory tu konkretnu sluzbu (protokol a port) je schopny spracovat. Na presmerovavanie by mohol pouzit napriklad iptables s modulom statistics. Vdaka tomu vie dynamicky reagovat na zmeny v poskytovanych sluzbach a beziacich serveroch prakticky okamzite. Samozrejme aj tych "prednych" serverov moze byt vela a ich IP by boli prave ako multi zaznamy v DNS. -
Filip JirsákStříbrný podporovatel
Ach so. Pak je samozřejmě otázka, zda je dobrý nápad všechno to schovávat pod jeden doménový název. Řešit se to dá aplikačním proxy serverem, routováním i NATem, nejlepší je podle mne ale použít různé DNS názvy. Třeba proto, že když někdo bude DDoSem útočit na web server, není nutné, aby tím rovnou sejmul i všechny ostatní služby.
-
Lol Phirae (neregistrovaný)
Ja som to pochopil tak, ze sa snazi dosiahnut nieco taketo: http://www.ideaz.sk/~bwpow/47/scr/loadbalancer.png
Ano, druhý nejpitomější návrh, co se dá vymyslet... hned po tom, kde se se místo somehost.somedomain použije pouze somedomain.
-
jouda (neregistrovaný)
LOL - útočník z kompromitovaného stroje ve vnitřní síti udělá díru do NATu... a proto je ochrana perimetru na nic. Další komentář netřeba.
Dám do DNS víc adres - aha, a z těch 10 IPček bude 9 vracet rst na portu 22, jiných 8 bude házet reset na 25, pět z nich na 80+443. Opět, radši bez komentáře.
-
IPv6 má adres dost, takže jediný důvod pro NAT padl. Proč bych ho měl chtít v síti mít?
Tak v korporátních sítích se jich najde dost. Třeba ten, že mají více poboček připojených přes lokální ISP a propojených VPN tunely a chtějí mít vlastní systém rozsahů IP podle poboček/měst/států a ne podle toho jakou IP jim v daném míste přidělí ISP. Tam se potom bez NATu (klidně statického 1 k 1) neobejdete. -
j (neregistrovaný)
Boze ... a nejaky duvod? Aspon JEDEN? Aha, naprosto zadny.
Pokud budu mit 158 pobocek tak to porad nemeni nic na tom, ze budu uvnitr mit verejny IPcka, a pokud je mi zatezko mit 158 rozsahu, ... ahhh stejne MUSIM mit 158 rozsahu. Ale pak uz je mi uprdele, jestli budou vsechny zacinat 1111:1111:1111 nebo kazdej jinak, zejo?
A i pokud vyznavam boztvo jednoho prefixu, tak to nemeni naprosto nic na tom, ze zadnej NAT proste nepotrebuju. Poridim si proste bud PI nebo vlastni AS, adresy si pridelim jak se mi bude chtit ... a providerum pres BGP poslu vzdy tu cast, ktera je v dany siti dostupna ...
...zazrak...
Mno a pokud sem velka korporace, tak mam stejne i vlastni kabely, a stejne se z tech pobocek nikdo nedostane na net jinak nez pres 1-2 uzly po svete, takze zase mam uvnitr zcela normalni verejny IPv6 adresy a na tech uzlech firewall, kerej resi co se smi a co ne.
... nemozny ... nikde zadnej ani jeden jedinej NAT.
-
IPv6 má adres dost, takže jediný důvod pro NAT padl. Proč bych ho měl chtít v síti mít?
Tak v korporátních sítích se jich najde dost. Třeba ten, že mají více poboček připojených přes lokální ISP a propojených VPN tunely a chtějí mít vlastní systém rozsahů IP podle poboček/měst/států a ne podle toho jakou IP jim v daném míste přidělí ISP. Tam se potom bez NATu (klidně statického 1 k 1) neobejdete.
-
On vůbec multihoming (resp. backup konektivita) menších sítí (tedy bez možnosti AS/BGP) se lépe řeší tím NATem. Představa, že při přepnutí linky mi celou sítí probublává SLAAC a mění adresy mě docela děsí. Ale existují lidi, co je to neděsí ...
NAT 1:1 je tedy podle mě v určitých situacích dobré řešení. A jelikož je statický, tak dopady na výkon nejsou v podstatě žádné. -
Filip JirsákStříbrný podporovatel
Mně teda NAT nepřipadá jako řešení záložní konektivity, spíš je to taková berlička, která umožní záložní konektivitu využít alespoň nějak. Vždyť s NATem tam máte single point of failure, při výpadku konektivity se nikdo nedostane po záložní lince dovnitř, rozpadnou se všechna navázaná spojení… Když nepoužijete NAT, ale zařízení budou mít normálně IP adresy od obou ISP, při použití SCTP výpadek jedné linky ani nezaznamenáte, pro TCP bude stačit znovu navázat spojení (z venku i zevnitř).
Je zajímavé, jak často dělají s NATem lidé z nouze ctnost a neumí si řešení bez NATu ani představit. -
Santiago (neregistrovaný)
Kazda diskuse o IPv6 zrejme drive nebo pozdeji skonci u reseni multihomingu pomoci adres od obou ISP. To je postup, ktery spolehlive nefunguje, nebot:
1) Kdyz vypadne jedna linka a prislusny router prestane announcovat RA do site, tak ho sice klienti prestanou povazovat za default gateway, ale to neovlivni platnost pridelenych adres.
2) Autokonfigurovane adresy jen tak nevyprsi, protoze minimalni lifetime je 2 hodiny.
3) V algoritmu vyberu zdrojove adresy hraje default gateway (a dostupnost jednotlivych bran) jen malou roli, takze klient, maje adresy z obou prefixu, i pri dostupnosti obou linek muze vybrat zdrojovou adresu od 'zalozniho' ISP a pri vypadku primarni linky adresu 'primarniho' ISP.
4) pouzita adresa a pouzita gateway jsou obecne nezavisle, takze klient muze pouzit zdrojovou adresu od ISP A a poslat to na gateway smerem k ISP B. Aby to fungovalo, tak brany o sobe musi vedet a predavat si vzajemne odchozi traffic podle zdrojove adresy.
5) I kdyby se body 1-4 vyresily, tak by to cele fungovalo jen na ploche siti, kde jsou klienti a brany na jedne linkove siti. Pokud ma sit vnitrni strukturu a vnitrni routery, tak by byl treba jeste nejaky dalsi protokol, rozsireni ci mechanismus, ktery by propagoval informaci o vypadku prislusne brany a ovlivnoval to, jake RA budou propagovat routery ve vnitrni siti. Existuje treba wg homenet, ktera by takove veci chtela resit pomoci rozsireni do routovacich protokolu, ale to je zatim spis experimentalni zalezitost.
-
Filip JirsákStříbrný podporovatel
To, že algoritmus výběru zdrojové adresy jde navrhnout tak, aby klidně vybral adresu od nedostupného operátora, neznamená, že se to tak musí dělat. A i když to tak někdo implementuje, neznamená to, že je to dobrá implementace.
To, že použitá zdrojová adresa a použitá brána jsou obecně nezávislé neznamená, že nejde zařídit, aby byly závislé. Ostatně běžně se to řeší i v multihome IPv4 sítích. Navíc to, že pakety se zdrojovou adresou od ISP A pošlu přes síť ISP by nemělo ničemu vadit, naopak, internet byl navržen tak, aby tohle bylo možné dělat. Pokud nějaký ISP místo zajištění bezpečnosti dělá hlouposti, může s tím mít problém, ale to je problém toho ISP, ne problém koncepce.
Multihoming se na internetu řešil odjakživa, to není žádná specialita IPv6.
IPv6 přináší spoustu nových možností, takže s postupným rozšiřováním budou vznikat i nové standardy, třeba pro snazší řešení multihomingu, aby si to každý nemusel dělat na koleně.
-
Santiago (neregistrovaný)
> To, že algoritmus výběru zdrojové adresy jde navrhnout tak, aby klidně vybral adresu od nedostupného operátora, neznamená, že se to tak musí dělat. A i když to tak někdo implementuje, neznamená to, že je to dobrá implementace.
Navrhnout a implementovat lze ledacos. Pokud ale mam heterogenni sit a nechci soustavne resit, proc to nekterym klientum dobre nefunguje, tak musim vychazet z toho, jake klientske chovani je predepsano standardem a take jak se chovaji bezne implementace. A tam plati to, co jsem psal vyse.
> Navíc to, že pakety se zdrojovou adresou od ISP A pošlu přes síť ISP by nemělo ničemu vadit, naopak, internet byl navržen tak, aby tohle bylo možné dělat. Pokud nějaký ISP místo zajištění bezpečnosti dělá hlouposti, může s tím mít problém, ale to je problém toho ISP, ne problém koncepce.
Naopak, ingress filtering zdrojovych adres podle routovacich informaci je AFAIK povazovano za best current practice (viz RFC 3704). Ze to spousta siti nedela, je jina vec.
> Multihoming se na internetu řešil odjakživa, to není žádná specialita IPv6.
Bezny multihoming propaguje adresy pomoci BGP, takze site po ceste vedi, ze provoz z danymi zdrojovymi adresami muze prijit z daneho smeru a je tedy povazovan za legitimni (feasible path RPF).
Krom toho, kdyby napr. behem vypadku linky od ISP A pakety se 'spatnou' zdrojovou adresou (tedy tou od ISP A) dosly nakrasne pres ISP B az k cili aniz by je nejaka sit po ceste odfiltrovala, tak cil odpovi na tyto 'spatne' adresy a odpoved tedy pujde cestou k ISP A, ktery je kvuli rozbite lince nemuze dorucit do multihomingove site.
-
Filip JirsákStříbrný podporovatel
Pokud ale mam heterogenni sit a nechci soustavne resit, proc to nekterym klientum dobre nefunguje, tak musim vychazet z toho, jake klientske chovani je predepsano standardem a take jak se chovaji bezne implementace.
Který standard definuje, že klient musí počítat s tím, že někdo bude modifikovat IP adresy v jeho paketech?Naopak, ingress filtering zdrojovych adres podle routovacich informaci je AFAIK povazovano za best current practice (viz RFC 3704).
To, že je něco považováno za best current practice, neznamená, že je to správně.Krom toho, kdyby napr. behem vypadku linky od ISP A pakety se 'spatnou' zdrojovou adresou (tedy tou od ISP A) dosly nakrasne pres ISP B az k cili aniz by je nejaka sit po ceste odfiltrovala, tak cil odpovi na tyto 'spatne' adresy a odpoved tedy pujde cestou k ISP A, ktery je kvuli rozbite lince nemuze dorucit do multihomingove site.
Což není vůbec žádný problém, protože při výpadku ISP A by se odesílatel měl snažit nepoužívat jeho zdrojové IP adresy. Podstatné je, aby to fungovalo, když je linka ISP A aktivní. -
M. (neregistrovaný)
Ad 1/2) Při výpadku jendé konektivity se udělá to, že se pošle preferred time 0, klientiu přestanou dané IP okmažitě používat.
Ad 3) Na totoje dneska již specifikace, aby se upřednstňovala zdrojová IPv6 adres adle brány s vyšší prioritou, ale asi to nic moc neumí.
Ad 4) Ano, klientui obvkyle jen použijí bránu s vyšíš prioritoua přeposlání mezi branami není problém, pokud to umí routery (linux dneska už policy routring pro IPv6 zvládá), aby to odešlo správnou linkouAd 5) Ano, ICMP/mechanismus pro rychlé přešíslování existuje, ale jak moc je podporován, to netuším.
Na síti, kde už ke hormada routerů, tak půjde už o velkou záíležitost, která to asi může řešit již metoudou vlastního AS, PI bloku adres a nepřečíslovává. Kde si vystačím s menší sítí, tak přečíslování funguje. Máme nasazeno a bez problémů na routerech od Mikrotiku přes několik poboček a v několika firmách, a tam je ta IPv6 ještě dost ochuzena o možnosti, ale i tam to jde udělat a funguje to. Interně se jede na ULA adresách a k tomu má klient globální adresu dle prioritní linky. Při výpadku se přečísluje na záložní (ULA zůstává) a jede se dál.
-
Santiago (neregistrovaný)
> Ad 1/2) Při výpadku jendé konektivity se udělá to, že se pošle preferred time 0, klientiu přestanou dané IP okmažitě používat.
Ano, explicitni odebrani prefixu ma vetsi sanci fungovat, nicmene i tam jsou pripady, kdy se to muze rozbit (napr. kdyz se router restartuje a po restartu nenabehne linka, vi, ze ma propagovat nejaky prefix s preferred time 0?) a je to IMHO daleko krehci reseni, nez pouziti NPT.
> Na síti, kde už ke hormada routerů, tak půjde už o velkou záíležitost, která to asi může řešit již metoudou vlastního AS, PI bloku adres a nepřečíslovává.
No, to muze byt i jen par wifi AP, ktere jsou nastavene v router rezimu. Zda je sit plocha nebo kosata a zda je velka nebo mala jsou IMHO vicemene nesouvisejici parametry.
-
M. (neregistrovaný)
Od toho jsou checking objekty, router si testuje pingem/BFD/... uplink a jeho funkčnost, ví jaký prefixy k tomu patří a dle toho případně i hned při startu začne na preffered time 0. Udělat explicitn odebrání (valid time 0) je ještě brutálnější. Ale co tuto techniku používáme v provozu tak 3 roky, tak s ní problém není. Rozhodně si nepamatuji, že by o duživatelů šla stížnost/report, že jim nefunguje síť, kde by byla chyba v tom, že měli IPv6 globální adresu od mrtvé linky.
Pokud s ohledme na IPv6 někdy je problém, tak je to Windwos 7+ a jména DNS serverů. Pokud je Win7 klient v síti, která mu přidějí i IPv6 adresy DNS serverů (přes bezestavové DHCPv6) a pak se přesune do jiné sítě, kde běží IPv6, ale nedojde k předání IPv6 adres serverů, tak mají snahu používat stále tu starou sadu z předchozí sítě, ale tohle je chyba Win7.Dobře, máme velkou síť (centrálu firmy), která jede metodou PI IPv6 bloku a ASka, což je cca 3 kKč/rok plus jendorázově více na start více (zd eje větší problém sehnat v místě dvě nezávisl konektivity přes ISPíky ochotné k BGP). Druhý koenc je SOHO, kde je to nesmysl, tak má dvě linky a použítá třeba ten hot renumbering.
Pokud chceš třetí střední velikost, která má už kaskádu pár routerů a nemá přiotom vlastní AS, tak i zde je řešení, pokud se síť konfiguruje pomocí DHCPv6-PD. Zkrátka pokud dojde k přečíslování u hlavního routeru, dojde k propagaci nových segmentů dolů přes DHCPv6-PD servery na jednotlivé routery. Nezapomínejme, že u DHCPv6 je už na rozdíl od DHCPv4 metoda, kdy server může dle potřeby kontaktovat klienta a sdělit mu novinky ohledně jeho dynamického přídělu, tak mu ho sebere a pošle nový. Nicméně přiznávám, že jsem neviděl takové řešení živé v praxi. Obvkyle z důvodů, že většina současných DHCPv6 implementací nemá impmentován kanál pro dodatečné "obtěžování" klientů. Ale je to asi otázka času, až to někdo do krabic namlátí. Dneska i na SOHO krabičkách od Mikrotiku tohle udělám, že hlávní router přes DHCPv6-PD od uplinku vezme blok, zapropaguje k podřízeným krabičkám a DHCPv6-PD servery/klienti to postupně se naučí a vyberou segmenty z přídělu a nasadí je a funuje to, ale není tam ta podpora pro změnu, obnovují příděl jen na restart/vypršení platnosti. -
j (neregistrovaný)
1) delat backup pres mutihome je hovadina, coz neznamena, ze to nejak nebude fungovat
2) adresy lze vpohode stahnout, protoze router posle info a klienti je zahodej
3) ..
4) src z jinyho rozsahu zcela bez potizi odejde (i na IPv4), specielne kdyz o tom ISP vi.=> zadny problem 1-4 neexistuje, protoze zalozni konektivita se resi za pomoci PI nebo vlastniho AS a plnotucnyho routovani s BGP. Coz zaroven znamena, ze netreba mit v siti vic rozsahu.
-
M. (neregistrovaný)
Dělat backup přes multihoming není blbost, ale i původní představa autorů IPv6. Pokud je to koncová síť, která se spojuje ven, tak multihoming s přečíslováním je původní představa autorů IPv6.
Později to Cisco doplnilo o představu použití NPT (což už je ten fuj bezestavový NAT), aby v síti nemuselo být víc prefixů.
Tohle je pro ty situace, kdy dneska je tam skoro SOHO router krabička s dvěma WAN porty, kdy to dle potřeby na IPv4 NATne na linku vlevo-vpravo.Metoda PI IPv6 blok a AS je až pro větší subjekt, už jen proto, že to něco stojí na poplatcích RIPE, provozu BGP atd. Takže ot je řekněme pro subjekt, co má být trvale dostupný ze světa.
A k tomu "src z jinyho rozsahu zcela bez potizi odejde (i na IPv4), specielne kdyz o tom ISP vi.", tak na to bych obecně se nespoléhal ani v případě, že o tom mů ISP víc, pokud daný ISP není i tranzitní pro další sítě, tak jeho uplinku dneska zcela reálně to mohou blokovat opět, že pustí jen IP z přídělu a nic jiného. Aneb dodržování BCP38 může být v tomto případě prevít. Takže je dobré se pak u takové multihomed sítě držet BCP84. :-)
-
Santiago (neregistrovaný)
> On vůbec multihoming (resp. backup konektivita) menších sítí (tedy bez možnosti AS/BGP) se lépe řeší tím NATem
Pokud mam ve vnitrni siti verejne adresy a nemusim mit NAT uz kvuli privatnim adresam, tak je reseni pomoci vlastniho AS a BGP jednoduche a relativne levne - poplatky RIPE jsou celkem 100 EUR rocne za ASN a PI prefix (+ to, co si prihodi LIR/ISP).
Nicmene souhlasim, ze pouzit NAT 1:1 je rozhodne lepsi reseni nez resit zalohu 'preadresovanim'.
-
Mne tu minule v diskusii k IPv6 tvrdili, ze "gud praktis" je mat viac IP adries na rozhrani. Jednu na vnutorne adresovanie po VPNke a druhu od lokalneho providera. Ak bude providerov viac, tak mat proste tych adries viac a ono sa to uz tymi IPv6 mechanizmami poriesi, ked nejaka cesta vypadne. Pride mi to ale absolutne zvratene.
-
bflmpsv (neregistrovaný)
> IPv6 má adres dost, takže jediný důvod pro NAT padl. Proč bych ho měl chtít v síti mít?
Jděte už s těma vašema pseudoargumentama. Proč bych chtěl NAT mít? Protože např. ztěžuje špehování uživatelů, znemožňuje jednoduše spočítat, kolik strojů je za NATem, zvyšuje bezpečnost, atd., atd... Důvodů je spousta, počet IP adres je ten nejmenší...
-
Janci (neregistrovaný)
>jak bys to udělal ty.
napriklad:a) rozsirit dlzku adresy IPv4, tak, ze 173.194.112.7 by bolo ekvivalentne s 0.0.0.0.173.194.112.7 a prefixov by bolo na rozdavanie
b) ked moze byt Q-in-Q tak preco nemoze byt IPv4-in-IPv4 ? zariadenia po ceste to ani nemusia podporovat, len tie na hraniciach
-
Janci (neregistrovaný)
a) v tom ze je to stale IPv4 len ma dlhsiu adresu, takze implementacia podpory je omnoho jednoduchsia, netreba vymyslat nejake prechodne mechanizmy, lebo je to spatne kompatibilne a podobne
b) pretoze na hraniciach sa prechaza mezi IPv4 a IPv6 sietou ktore su nekompatibilne, tu by sa len vybalil paket z vonkajsej obalky a dalej by isiel zase IPv4
-
Janci (neregistrovaný)
1) nie, pripojovali by sa stale na tie povodne sluzby pomocou povodneho ipv4 bez nutnosti dualstacku
.. boli to prve dve veci co ma napadli, nerozoberam to do detailov, ale moznych rieseni problemu nedostatku IPv4 je vela, niektore lepsie, niektore horsie a co je fakt tak IPv6 ktore bolo vybrane ako riesenie sa nasadzuje pomaly a nasadzovaci akurat fnukaju ze ostatni nenasadzuju a ti co nenasadzuju tak problem nemaju
-
Jenda (neregistrovaný)
> 1) nie, pripojovali by sa stale na tie povodne sluzby pomocou povodneho ipv4 bez nutnosti dualstacku
A jak se připojím ze sítě IPv4+ na IPv4 službu, když jí pošlu paket, který má jako SRC adresu „nějakou dlouhou“ a ona mi odpoví na první čtyři bajty? Někde cestou nejspíš bude muset sedět krabice, která to spojení bude sledovat, a odpověď zpátky rozšíří o ty další čtyři bajty. Právě jsem popsal NAT64.
> .. boli to prve dve veci co ma napadli, nerozoberam to do detailov, ale moznych rieseni problemu nedostatku IPv4 je vela
Ne, to, co jsi navrhl, prostě není jednodušší než IPv6. Stejně jako IPv6 to prostě vyžaduje podporu u koncových poskytovatelů a klientů. Nevyžaduje to podporu na páteři, ale s tou právě problém není.
-
j (neregistrovaný)
Dalsi placal co zvani o vecech o kterych nema paru. Ta prekombinovana IPv6 redukuje pocer pravidel firewallu (klidne o rad), redukuje pocet zaznamu v bgb (mozna o 2 rady) a umoznuje veci, o kterych si IPv4 muze nechat leda zdat.
A jak bylo receno, existence NATu ma jede jedinej duvod a tim je prave nedostatek adres. Velmi brzo bude ovsem i nedostatek portu, a na ten uz jaksi lek nemame.
-
j (neregistrovaný)
Narozdil od tebe nemam uvnitr zadny privatni adresy, ale verejny. A tudiz se neuplatnuje zadny NAT a nemusim resit, z ktery strany paket prijde. Divny co?
Nevsim sem si, ze by se na IPv6 menila adresa paketu cestou pres router, takze je vazne nepotrebuju markovat. Narozdil od jebleho NATu, protoze tam se samozrejme zmeni. Opravdu by me zajimalo, jak by si tvoje malickost predstavovala shapovani 100 lidi ... na jedny IP ...
-
j (neregistrovaný)
Chmm ...
wc -l firewall_ipv6
136 firewall_ipv6wc -l firewall_ipv4
373 firewall_ipv4Jeden router, obe dela presne totez. Pomerne jednoduchy nastaveni, zadny slozitosti.
ipsec nic? muticast nic? mobility nic?
Ale jo, on je urcite kazdej provider stestim bez sebe, kdyz dou vsici sledovat nejakej fotbal/hokej/... a tech rekneme 5Mbit mu do site leze bambilionkrat. A stejne tak je nadsenej z toho, kdyz misto aby si to porno vymenili mezi sebou, tak ho nejdriv tlacej na ulozto, a pak sosaj zpet.
-
Santiago (neregistrovaný)
> redukuje pocet zaznamu v bgb (mozna o 2 rady)
Na globalni urovni tak maximalne o jeden rad. V globalnich BGP tabulkach je ~580k IPv4 prefixu a ~50k ASNs. Takze i kdyby si kazdy AS vystacil jen s jednim prefixem (coz nemusi napr. kvuli traffic engineeringu), tak bychom pri plnem nasazeni IPv6 (a soucasnem mnozstvi AS) meli ~50k IPv6 prefixu.
-
M. (neregistrovaný)
Vidím to trochu jinak. Drobení je jedna věc, ale to asi pod /24 v BGP nepůjde.
Vidím dneska ale masovku už jinou, a to je tunelování IPv4 křížem krážem. A to hlavně z pohledu poskytovatelů server hostingu a spol.
Nemají IPv4 adresy, tak nakupují klidně malé bloky ud od /28 a tunelují je, takže když pronajmu takto část svých IPček, tak se nepublikuji v BGP, ani si hosting nedá servery do mé sítě, ale zkrátka je ze své sítě pošlu přes GRE tunel k hostingu a občas je sranda vidět, kudy a jak se ten paket ve skutečnosti motá v celkové trase.
Takže pomalu začíná IPv4 svět postihovat takto to, čím trpěl IPv6 v době tunelovaní z místa na místo, než zaačo nativní transport stoupat.
Zkrátka se cesta prodlužuje, jak je neoptimální routing, často prochází přes celkem "tenké" linky u koncových ISP tam a zpět, kteří takto poskytli své nadbytečné IP, občas stále do toho pak zasáhne problém zkráceného MTU, pokud je použit holý IPIP/GRE, .. -
Filip JirsákStříbrný podporovatel
Já doufám, že tohle prodlužování trasy a zužování pásma IPv4 konečně povede k rozšíření IPv6 u koncových zákazníků. Protože „IPv6 = rychlejší internet“ je konečně něco, co se se dá napsat velkým písmem na krabici a prodat.
-
Jak už jsem psal výše, těch důvodů je více než jen nedostatek IP. Hlavně v korporátních sítích, kde jsou pobočky v různých lokalitách připojené přes různé ISP a propojené VPN tunely a chtějí mít vlastní management IP adres podle třeba pobočky/města/státu bez ohledu na IP které přidělí ISP. Další věc je redundance přípojek od různých ISP do jedné pobočky (= různé prefiy IP) tak, aby nezáleželo na tom, přes kterého ISP se komunikuje
-
Ondřej CaletkaZlatý podporovatelKorporáty, které mají více poboček a chtějí mít adresování ve vlastní režii, jsou ideálními kandidáty na získání vlastního bloku adres a vlastního AS.
V jednotlivých pobočkách pak skrze lokálního ISP anoncují tu část svého bloku adres, která patří té které pobočce, mezi pobočkami jim může běhat třeba Site-To-Site IPSEC. Takže se jim to chová přesně jako ta stávající privátní síť, včetně VPN tunelů, přitom ale mají jen jednu sadu adres na všechno…
Ostatně, tohle přesně řeší třeba Kaufland, jehož člověk stojí za návrhen uvolnění pravidel RIPE pro podmínky alokace IPv6 adres. Ty totiž dříve reflektovaly jen „očekávaný počet zákazníků“, což je sice dobré měřítko pro ISP, ale na velké korporáty, které chtějí adresy hlavně pro sebe, se to vůbec nehodí.
