Vlákno názorů k článku IPv6 roste, Google hlásí 12 %, chce to ale víc uživatelů od Petr M - Myslím, že "hodně dobře" je na tom s...
-
Petr M (neregistrovaný)
Myslím, že "hodně dobře" je na tom s IPv6 i Ubiquiti nebo Mikrotik, první volba WiFi ISP... A přes to jaksi nejede vlak, pokud mu někdo nevykope tunel :(
A protože tunel je pomalejší a s menším MTU, co asi bude na koncovým zařízení preferovaný? A není páka, která by to změnila.
-
Ondřej CaletkaZlatý podporovatelKéž by i O2 byl normální poskytovalel… Na druhou stranu, vždycky jde přejít k T-mobile DSL ;)
-
Lol Phirae (neregistrovaný)
Když mi někdo zakáže
Kdo ti to zakázal? Ta hovadina je v Linuxu (a některých *BSD) už drahnou dobu implementovaná. To, že to správci zásadně odmítají přidávat jako funkci do různých firewall distribucí typu pfSense, má kurva dobrý důvod - totiž tupost jedinců tvého typu, kteří by to okamžitě začali používat ve stylu IPv4 NATu.
co já potřebuju
K čemu?
s výhodou mohu použít.
A v čem je ta "výhoda"?
-
j (neregistrovaný)
Vyhody sou v tom, ze jim to umozni zkurvit konetivitu, protoze tihle bridilove vubec netusej co je to routovani a jak to funguje. Natoz aby tusili, ze na 6tce muze mit kazdej stroj libovolny mnoztvi adres (a prefixu) a ze jim (WOW) dokonce muzes dorucit nekolik rout s ruznou prioritou ... a pripadne ji kdykoli obratem odstranit.
A samo NAT je prece chrani pred vsim zlem ... protoze firewall je pro ne sprosty slovo a nemaj paru jak to funguje.
-
Mícháte dynamický NAT (který skutečně u IPv6 postrádá smysl) s NAT 1:1, který má praktická uplatnění a ničemu nevadí. Natož aby vadil nějaké konektivitě. Vadit by mohl end-to-end šifrování, pokud to šifrování ověřuje koncové IP adresy. Jenže to jde proti dalším (novým) technologiím, které změnu IP adresy předpokládají (např. když přejdete z LTE sítě do WiFi). Takže to nakonec logicky nevadí ničemu.
-
M. (neregistrovaný)
NAT1:1 v podání IPv6, asi hlavně překlad prefixů (NPT), tak sice je to hezky vypadjaící cesta na řešení některých situací jako je stav, že mám LAN udělánu na ULA adresách a na bráně podle odchozího směru přeložím jen prefix za jiný podle odchozí linky "bezestavově", ale nedá se na to dívat jako na spolehlivou cestu. Sice to nebrání volnému průchodu oběma směry, ale přímo i specifikace NPT uvádí, že autoři aplikací a protokolů nemají své návrhy komplikovat mechanismy, které umožní fungování přes takové typy překladů a je na uživatlei se smířit s tím, že něco fungovat nebude....
Tak je to takové z bláta do poloouže. Ale neřeší to ani problém, když mám jen jenden prefix /64 a chci z něj udělat víc LAN segmentů.
Např IPsec po IPv6 přes to nefunguje....
situace přechodu z LTW na wif se dá řešit různými způsoby, IPv6 nabízí několik mobilních mechanismů, ale moc běně to implementováno není. To sna duž MOBIKE je častější, jako MobileIP. -
MZ (neregistrovaný)
Pokud jde o to, že poskytovatel Internetu přidělí jen jednu síť /64 pro uživatele, tak to teoreticky jde nastavit tak, že ISP propaguje v RA prefix /64. Router pak tento prefix naučený z WAN portu přesune na vnitřní rozhraní LAN a propaguje ho pro domácí počítače. S routerem poskytovatele pak komunikuje přes link local. Pouze by musel všechny pakety přicházející z link local z WAN portu posílat na LAN a naopak a mohlo by to fungovat. Asi by se hodila nějaká logika, aby nepřeposílal provoz z lokální sítě, který nemá jít do Internetu.
Žádný NAT, jen prostředky, co nabízí IPV6. Nenašel jsem to nikde jasně popsané, ale v podobném režimu by to mělo nějak jít. -
M. (neregistrovaný)
Nejmenší přidělitelný prefix je /64, čehož se řada místních "ISP" drží jak jen můžou a víc dát zdarma nechtějí. Buď proto, že mají jen jeden PI blok /48 (nebo /48 PA od svůho uplinku), takže s příděly /56 na koncáka toho moc neoblouží nebo to vidí jako obchoní případ a za každý další blok /64 chtějí třeba 120 Kč/měsíc, viz O2.
Což je v podstatě i v souladu s doporučneíkm RIPE a RFC, akorát trochu vynechávají tu druhou část, že koncák by měl obvykle dostat výrazně více (než jen /64), aby nebyl nucen do blbostí typu IPv6 NAT....
Dávat blok /56 není snad nikde normován, je to jen dopručení. Také se používá z pohledu alokačních výpočtů využití přidělů ISPíkům.Takže pokud je Milan na línce nějakého takového vydřiducha/škudlila s /64 per koncák a není moc podobně drahá alternativa v místě, tak se nedivím, že má touhu po věcech typu IPv6 NAT. Nicméně záleží dost na zařízení, co má. Mikrotik neumí třeba NAT pro IPv6 (snad s ROS7 to bude lepší), ale jde na něm nakonfigurovat, abych s jednou /64 měl oddělené sítě třeba pro domácí a návštěvu, kdy na IPv4 má každý jiný blok a pro IPv6 se od sebe odděleni a nevidí se, přestože sdílejí jen tu jednu /64. Ale je to takové drbání, kde s větím přídělem se to řeší naprosto přímočaře.
-
M. (neregistrovaný)
Jenže to znamená, že si ISP musí požádat u RIPE/LIRa o příděl, což znamená zaplatit vstupní poplateček a pak platit roční poplateček, což naprostá většina ISP odmítne, že to je drahé/složité/...
Tím pádem totální většina ISPíků si vezme jen to, co jim dá jejich uplink, což je obvykle tak jeden-dva bloky /48 a pokud chce víc, tak jej odkáže na RIPE.... Pak pár si případně koupí vlastní PI prefix /48 za jednorázovou platbu u ISP servisu (který vůbec nneí určen k provozu pro ISP, ale vesele se tak často používá)....
Takže těch, co absolvují to do zdárného konce s vlastním AS, vlastním /32 IPv6 přídělem a ještě trochu IPv4, co se z posledního dává, tak těch je totální minorita. -
MZ (neregistrovaný)
Nevidím důvod, proč by každý ISP musel být členem RIPE a dostat svůj vlastní prefix a navíc dávat opravdu každému /56. Nyní je cca 30 000 prefixů ve světové IPV6 tabulce. V CR je podle nějaké stránky cca 1 000 ISP. To by byly asi 3% světové tabulky, kdyby každý z nich měl svůj vlastní prefix /32. ČR má 10 mil. obyvatel, tj. 1 ISP na 10 000 osob. Se stejným poměrem ISP na počet obyvatel světa to dělá 300 000 prefixů (počet obyvatel 3 mld, aby se to dobře počítalo).
Počet ISP je u nás možná větší než jinde, ale i tak, musely by se pořizovat výkonnější routery, pokud každý ISP měl
svoje adresy. Plus dost kapacity pro stávající tabulku ipv4, to je cca 550 000. Každý zásah, který může zvětšit zbytečně zvětšovat světové BGP, by se měl promyslet.Pokud menší ISP není členem RIPE, tak by z prefixu /48 mohl mít maximálně 256 zákazníků, pokud by rozdával /56 každému. Pokud by dostal o bajt víc - /40, tak by takových zákazníků mohl mít 65 5636, což by v českých poměrech mohlo stačit, i kdyby měl několik velkých zákazníků s prefixem /48.
Ovšem větší ISP (např. Dial telecom) má obvykle prefix /32, takže by mohl připojit max. 256 menších ISP./48 - 2 bajty na sítě, 256 prefixů /56 nebo 65 536 prefixů /64,
/40 - 3 bajty na sítě, 65 536 prefixů /56 nebo 16 777 216 prefixů /64,
/32 - 4 bajty na sítě, 65 536 prefixů /48 nebo 16 777 216 prefixů /56 nebo 4 294 967 296 prefixů /64 -
Sten (neregistrovaný)
Nebo by takový ISP mohl dávat /60. Měl by pak dost adres pro 4 096 klientů, což by mu mohlo stačit, a 16 síti by stačilo naprosté většině zákazníků. IPv6 je primárně dělené na nibbly místo na bajty, jako to bylo u IPv4 (např. u reverzů), takže by s takovým prefixem problém nebyl.
-
M. (neregistrovaný)
Problém je v tom, že ten koncový ISP nedostane ten prefix /40 od svého data carriera, protože ten ISP vystupuje obvykle v roli ne ISP, ale koncového zákazníka. Takže podle pravidel RIPE má koncový zákazník dostat max /48. V případě hodně velkéhe zákazníka má dostat /47, ale pak si RIPE žádá vysvětlení, proč tomu tak je.
Sice pravidla RIPE očekávají, že datacarrier (v roli LIRa), který je členem RIPE, může přidělovat i prefixy koncovým ISP, kteřív RIPE nejsou, ale pro takový případ nechává pravidla na tom data carrierovi, jak si to udělá. A třeba zrovna zmiňovaný Dial nedá víc, jak /48, respektive dá několik /48, pokud jako ISP mám k němu několik linek, tak na každou dá jednu /48 (ani nenavazující bloky na sebe). Když chci víc, tak mě pošle, ať si to sám vyřídím u RIPE. Možná proto, protože by pak měl dle RIPE pravidel, že by za toho ISP ml provádět registraci jendotlivých bloků přidělených skrz toho ISP na koncové zákanzíky v DB RIPE.
A na tom právě většina těch malých ISP to zabalí, že se s tím nechce nechce otravovat, natož něco platit, že radši koupí další rádio, tka vezmou tu jendu /48 a škudlí s ní....
O fous s eto zlepšilo v poslední době, kdy se zoufale několik ISP do náruče RIPE a získání vlasntího /32 IPv6 bloku vrhlo jen proto, že chctějí pro sebe ještě něco utvat z toho zbytlu IPv4, co k tomu RIPE dává (takže pak nakonec stjeně nasadí jen to IPv4 a IPv6 nechávají ležet do doby, než jejich management to bude umět, viz o pár příspěvků níže). -
M. (neregistrovaný)
Protože to měla být odpověď o příspěvek výše.
Jinka souhlasím, také to dělám tka, že home přípojky fasují /60, ale daší lidi dávám tak, aby byla mezera na /56 a zahušťovat segment začnu, až dojde. Malé firmy fasují /56 opět s dírama atd. Podobnou technikou se dá i s jednou /48 vydržet dlouho. :-) -
Santiago (neregistrovaný)
> Problém je v tom, že ten koncový ISP nedostane ten prefix /40 od svého data carriera, protože ten ISP vystupuje obvykle v roli ne ISP, ale koncového zákazníka. Takže podle pravidel RIPE má koncový zákazník dostat max /48.
Nojo, jenze koncovy ISP nemusi vuci LIRovi vystupovat jako zakaznik. RIPE zavedl pravidla pro sub-alokace, takze namisto, aby LIR koncovemu ISP ten prefix /40 assignoval jako koncovemu zakaznikovi (coz by porusovalo pravidla), tak mu ten prefix muze sub-alokovat, viz:
https://www.ripe.net/manage-ips-and-asns/resource-management/faq/sub-allocation
Subalokace ma slouzit prave pro resellery, ci downstream providery, kteri sami nejsou LIRove.
-
M. (neregistrovaný)
Ano, to sice existuje, ale LIRům se evidentně nechce ALLOCATED-BY-LIR pro subdelegaci u IPv6 používat moc nechce. Asi jde o to, že pořád to mají na krku a odpovídají za stav těch sebdelegovaných bloků vůči RIPE a chce to pak rozumně oetřovat smluvně s těmi koncovými sítěmi. A jejich přístup k řadě věcí je v cleé řadě případů dost katastrofa...
Subdelegace jen řeší, že si to může definvoat koncový ISP, kterému něco subdeleguji. Možná hraje i zkušenost, že většina koncových ISP, stejně kašle na vyplňování ČTU formulářů, natož RIPE DB... :-)
ČLÁNKY DO MAILU