Názory k článku Praktické zkušenosti: nasazení IPv6 v síti poskytovatele
-
Bedňa (neregistrovaný)
Tu je to, ale bez manuálu to nedáš :-)
http://www.ripe.net/lir-services/ncc/gm/november-2011/documents/draft-ripe-ncc-charging-scheme
-
Podle me se s IPv6 adresama strasne plytva. Panove se tady podivuji, ze dostali jen /48 prefix, a ze jim vubec nestaci, ze tim pokryji pouhych 255 zakazniku. Boze co je tohle za blbou praxi? Vzdyt v /48 prefixu je miliarda miliard adres! Vzdyt je tam vic volnych adres nez je v celem IPv4!
Naprosto nechapu proc se takhle s tema adresama plytva. Kdyz kazdy dostane prefix /48, tak sme za chvili tam kde sme dosli s IPv4.
-
Martin Kučera (neregistrovaný)
Vítejte do světa IPv6!
Tak to je prostě vymyšlené. Samotná adresa je sice /128 ale rozdávat musíte /64 (kvůli automatické konfiguraci) a pokud chce mít uživatel vlastní síť, tak mu musíte dát /56
Ale vlastně to moc nevadí, protože adres je fakt HODNĚ a používané adresy mají vyhrazené nějaké úvodní bity. Takže když se časem ukáže, že jdeme špatnou cestou, ještě pořád bude zbývat veliká hromada adres, kde můžou být pravidla úplně jiná.
-
Autor IP se nechal slyšet, že kdyby věděl, že se síť tak rychle a mohutně rozroste, tak by 32b nikdy nepoužil.
Jinak, v IPv6 to má být tak, že ISP (kterých může býti 4mld, což je stejně, jako všech IPv4 adres dohromady) dostanou /32 a svým 65tis. zákazníkům (to už máme počet, který se na naši planetu nevleze: 262 tisíc miliard = 262 bilionů zákazníků).
Opravdu bych se nebál, že to někdy dojde.
-
Jirik (neregistrovaný)
IPv6 by se melo uplne zahodit a pouzit neco lepe vymysleneho. At uz jde o velikost adresoveho prostoru a nebo subnety. Kdyz delali 4 tkay si mysleli, ze to staci. A ejhle, IP ma kazda mala blbost vcetne nekterych hodinek.
Clovek by si rek, ze dnes se uvidi dal, ale prd. Neni daleko doba, kdy IP bude potrebovat kazda skoucastka na aute napriklad. A zase tu bude chaos nanovo. -
Jenda (neregistrovaný)
1) Navrhni.
2) 2^128 už je pro Zemi fakt dost (i na ty součástky v autě). Docela hezky to ilustruje https://xkcd.com/865/. Pokud se někdy v budoucnu dokážeme dostat na jiné planety, stejně se místo IP bude muset vymyslet nějaký jiný protokol.
-
Pavel Trefný (neregistrovaný)
Co agregace :-) si delate srandu :-) do globalni tabulky jde jen /32 a tam se vejde nesmyslu typu /126 :) Interne u nas se drzi politika co uzel to /56, takze taky proti IPv4 zadna zasadni zmena.
Pokud se bavime o IPv4 tak to postupem casu bude problem az vsichni vypropagujou svoje posledni pridelene site /22 :)
Ono totiz kdyz si kazdy z LIRu vypropaguje svoje "male" /32 a nizsi subnety tak routovaci tabulka pro IPv6 nebude nikdy vypadat jako ta stavajici pro IPv4.
-
SB (neregistrovaný)
Teď jste mě trochu rozhodil - borec, který vytváří výborný Slax, nechápe, že autoři IPv6 velice chytře rozdělili adresu IPv6 tak, že pravých 64 bitů patří vždy LAN, tudíž se nemůže stát, že jako vlastník oné LAN dostanete jedinou adresu a zbytek budete muset omrdat NATem, neboli je garantováno, že žádný posraný NAT nebudete potřebovat, což samo o sobě znamená návrat k původní idei přímo propojených zařízení (to jsou vymoženosti, co?). Po kolika letech?!!! Osobně to považuju za průlomové. S nadsázkou: IPv6 už neadresuje jednotlivá uživatelská zařízení, ale LANy, a nedělá to 32bitovou adresou, ale 64bitovou adresou (ponechávám stranou problematiku podsítí s kratšími prefixy). Vnitřek LANu si řeší uživatel sám.
(Drsní síťaři mi prominou případné nepřesnosti.) -
To bude nejspíš nedostatkem informací.
NetworkManager 0.9.6, testováno na všechny běžné scénáře konfigurace proti radvd a ISC dhcp.
Scénáře a konfigurace zde:
https://fedoraproject.org/wiki/Networking/Addressing#Dynamic_IPv6_configuration
-
Santiago (neregistrovaný)
> že pravých 64 bitů patří vždy LAN, tudíž se nemůže stát, že jako vlastník oné LAN dostanete jedinou adresu a zbytek budete muset omrdat NATem, neboli je garantováno, že žádný posraný NAT nebudete potřebovat, což samo o sobě
Tohle neni uplne pravda. Kazda LAN sice dostane /64, ale uzivatel nemusi dostat zadny vlastni /64 prefix, muze byt pripojen pres jedinou IPv6 adresu ve sdilene LAN poskytovatele (napr. pri pripojeni pres ethernet ci wifi).
-
SB (neregistrovaný)
Uživatel určitě nedostane prefix /64, ten je pro podsíť. Uživatel (rozhraní) dostane (jestli to dobře chápu) vždy 1 až několik konkrétních adres podsítě (případně nějaký prefix pro snadné směrování, třeba /124). Nutit uživatele mít jen jednu IPv6 a vytvořit NAT, je podle mě proti smyslu IPv6 a je to chybou návrhu adresování sítě a nedává to smysl. Ale to je zase otázka na síťaře.
-
„Uživatel určitě nedostane...“
„Uživatel (rozhraní) dostane (jestli to dobře chápu) vždy“
Nic z toho není obecně dáno. Uživatel dostane to, co si nasmlouvá u operátora. Tedy jednu IP (pro jedno zařízení), několik IP (pro pevně daný počet zařízení) či celý rozsah.
Pro operátora je technicky nejjednodušší dát celý rozsah, pokud se k zákazníkovi dává nějaký router. Pokud dělá cokoli jiného, je to aktivní buzerace.
-
Palo M. (neregistrovaný)
V Slax-e sa tiez neplytva a do 200MB sa zmesti tolko, co je inde nepredstavitelne. Takze ten nazor mi pripada uplne konzistentny s osobou ktora ho vyslovila. Navyse, kazdy ma pravo na nazor a nemusime s nim sice suhlasit, ale dehonestovat nazory inych by sme nemali (narazam na tvoje "borec... nechape, ze..." - to si podla mna fakt prehnal).
-
Filip JirsákStříbrný podporovatelVýchozím nastavením firewallu v zákaznickém routeru je jednoduchý stavový filtr, který nepropustí do sítě zákazníka nic zvenčí, pokud zákazník nenaváže spojení sám. V podstatě to má stejný bezpečnostní účinek jako NAT u IPv4.</um>
To by ten firewall musel být hodně děravý, aby měl stejný bezpečnostní účinek, jako NAT.
-
Filip JirsákStříbrný podporovatel
Co myslíte, že se stane, když na vnější rozhraní toho vašeho NATu dorazí paket s cílovou adresou 10.0.24.12? Já tipuju, že si ho NAT ani nevšimne a pošle ho do vnitřní sítě na váš počítač.
-
Pořád všichni pochybují o "firewallových" účincích NATu. Uvědomte si, že popisovaná zranitelnost NATu platila pouze pro dávný návrh fyzicky symetrického NATu. To je dávno pryč. Současné NATy mají jasně odlišené veřejné a vnitřní rozhraní. Dokonce u *WRT je na tom postavená bezpečnost služeb, které se nabindují jen na vnitřní IP adresu a zvenčí se na ně bez port forwardingu nejde dostat.
I kdyby ten NAT byl hloupě symetrický, jakože není, stejně by se tam muselo chodit ze stejné podsítě poskytovatele bez použití brány. Poskytovatelé, aspoň ti větší, dělají Guest Isolation, což například předejde tomu, aby si lidi v paneláku navzájem četli sdílené dokumenty.
Vím, že existují i způsoby zapouzdření paketu, aby se objevil až v cílové síti, ale ten zase musí někdo dekódovat, takže to v podstatě předpokládá hack/špatnou konfiguraci něčeho jiného a pak se někam lámat s úrovní důvěryhodnosti místní sítě. -
j (neregistrovaný)
A vy, blbec, porad odmitate pochopit, ze !ROUTER! pakety (pro vas velke prekvapeni) !!! ROUTUJE !!!, a co ze udela router s paketem, kterej ma adresu v rozsahu kterej zna? Ano presne to, co se od routeru ceka, posle ho tam.
=> zadny NAT neni absolutne nijak bezpecny, je treba (a vzdy byl a bude) FIREWALL.
-
Jenda (neregistrovaný)
Myslíte net.ipv4.conf.all.rp_filter, což implementuje sekci 5.3.8 rfc1812? To dělá validaci source adresy, to u trafficu z Internetu nepomůže, ne?
-
j (neregistrovaný)
Ty vykricniky tam jsou predevsim proto, ze porad nejaky blbci tvrdi, jak je NAT ochrani, a BFUcka tomu pak verej. A tady vidim dalsiho v rade, neb nevi o cem pise. IP spoofing protection ma kazdy normalni router vypnuto, protoze jinak by nemohl fungovat - za normalni router rozhodne nepovazuju router, ktery funguje jako gateway dvou siti (pricemz jedna znich je koncova), ale zarizeni, ktery ma konektivitu do siti nekolika a vzhledem k principu routovani mu tudiz muzou prichazet (a taky prichazeji) pakety z ruznych smeru.
-
Filip JirsákStříbrný podporovatel
Spíš v sítích, kde se chtějí dostat na web, i když jim vypadne primární konektivita. Protože když to řeší až na routeru za tou spadlou linkou, stejně se rozpadnou i všechna odchozí TCP spojení a příchozí provoz nejde vůbec. Takže pokud někdo chce opravdu zálohovat konektivitu, řeší to třeba IP tunelem, VPN nebo PI adresami.
-
Filip JirsákStříbrný podporovatel
Jistě. Pro každý problém existuje jednoduché, snadno pochopitelné špatné řešení.
-
Jediné správné řešení je PI, ale to už nikdo nikomu nedá, protože je RIPE už nepřiděluje. Nehledě na to, že pro malou firmu nebo domácího uživatele je to prostě s těžkým dělostřelectvem na vrabce.
Při NATu se samozřejmě stávající spojení rozpadnou, pro většinu věcí to ovšem nepředstavuje zásadní problém.
-
To je bohužel blbost. Neexistuje žádné jednoduché řešení, které by zajistilo změnu IP adres - DHCP timeouty rozhodně delší než pár vteřin, které trvá přepnutí NAT. Nehledě na to, že přes ten NAT se dají dělat i zajímavější věci, jako třeba rozdělování zátěže - z ulož.to tahám jednou linkou, skype jede druhou.
-
Filip JirsákStříbrný podporovatel
Nejlogičtější a zároveň nejjednodušší řešení je, že mají zařízení IP adresy pro obě konektivity. Dobře se tím řeší dostupnost z venku, v případě výpadku konektivity nebo i jen routeru pro danou konektivitu prostě zařízení automaticky použije výchozí bránu s nižší prioritou. Náhodné rozdělování zátěže můžete jednoduše řešit tak, že některým zařízením nastavíte jako prioritnější jednu konektivitu, ostatním jinou. Rozdělování zátěže podle typu už vyžaduje dostat podrobnější pravidla pro routování až na koncové zařízení, ale předpokládám, že tím směrem se to bude rozvíjet. Ostatně rozhodování na základě toho, jaká je dostupná konektivita, se dnes vyžaduje od každého chytrého mobilu, a to ten mobil není v žádné síti, kde by mu s tím někdo pomohl – prostě má dvě či více úplně nezávislých připojení, a musí si s tím nějak poradit. Takže počítače v síti by to taky mohly zvládnout, a lednička holt použije tu bránu, kterou jí doporučil router.
-
Tak jednoduché to není. Důležité pro ustanovení spojení je volba zdrojové adresy. V případě výpadku vnější konektivity jedním směrem se tyto adresy musejí nějakým způsobem zrušit i na koncových počítačích, aby si náhodou nezvolily tuto adresu jako výchozí (a tím pádem nejely, protože budou tím druhým providerem zaříznuty). A o žádném takovém protokolu, který by adresy z rozhraní rušil nebo jim dával nižší prioritu nevím.
-
Filip JirsákStříbrný podporovatel
V případě konektivity jedním směrem to koncový počítač nejpozději při pokusu navázat tímto směrem spojení zjistí. Takže si danou routu označí za nedostupnou a použije další routu podle priority. Podle routy zvolí cílovou a výchozí adresu a jede. Žádné rušení adresy z rozhraní dělat nebude, protože na této adrese je pořád dostupný třeba v rámci lokální sítě.
-
Filip JirsákStříbrný podporovatel
Unreachable a redirect jsou dvě různé věci. Když nebudete používat NAT, můžete používat IPsec, a pak řízení směrování pomocí ICMP paketů žádné bezpečnostní riziko nepředstavuje.
O tom, že dvě konektivity nelze používat bez NATu, mne nepřesvědčíte. Můj mobil má jednu konektivitu přes WiFi, druhou přes GSM, a jsou to dva úplně odlišní ISP. Takže kdybych měl určit, co je ta síť, která podle vás musí být schovaná za NATem, byl by to celý český internet, a někde v NIXu by byl obrovský NAT, přes který bychom se teprve všichni připojovali do internetu. A to bych s tím mobilem nemohl opustit ČR. Věřte mi, že v NIXu žádný takový obří NAT, za kterým by byl schovaný celý český internet, není. No a když ty dvě konektivity bez NATu zvládá můj mobil, vaše pécéčko by to taky mohlo umět, nemyslíte?
-
Uvedl jsem ICMP redirect proto, že to je patrně ta správná metoda pro přesměrování provozu.
Netvrdím, že dvě konektivity nelze používat bez NATu, to jste četl asi něco jiného, než jsem psal. Příklad s mobilem je úplně mimo, protože je to koncové zařízení se dvěma konektivitami, narozdíl od koncového zařízení připojeného připojeného pouze jednou linkou k upstream konektivitě.
S tím NIXem mi nevnucujte, co jsem neřekl. Do NIXu jsou připojeni privideři nebo zákazníci s PI adresami a používají BGP, čili úplně jiná situace než klasická malá firma, která vlastní AS ani PI adresy nemá.
V IPv4 bez NATu prostě podle mne neexistuje metoda, jak říct koncovému zařízení, aby změnilo algoritmus IPv4 SAS (source address selection).
-
Filip JirsákStříbrný podporovatel
Já ale nechci přesměrovávat provoz, chci jenom oznámit, že daná síť je přes daný router nedostupná. Celou dobu tady řešíme případ, kdy zařízení má pro přístup do internetu dvě konektivity. IPv4 s NATem rozhodně není metoda, jak říct koncovému zařízení cokoli o routování. Např. OSPF je takovou metodou. Navíc tady řešíme IPv6, a to má trochu jiné předpoklady a jiné možnosti, než IPv4.
-
M. (neregistrovaný)
Hlavně myslím, že se dohadují lidi, co to nikdy nezkusili?
Funguje to. A bez vážnějších problémů. Situace:
LAN koncová síť, k ní připojeny dva routery (Mikrotik), každý router má uplink k jinému ISP, od každého má jiný blok /48 globálních adres. každý router propaguje ten svůj (respektive patřičný /64 do LAN, wifi, ...). Vedle toho je ještě aktivní blok ULA adres, které se používají pro spojení do firmy skrz VPN tunel, ULA propagují shodně oba routery.
Krámy v síti používají spokojeně IPv6 (Win XP, Win 7, Nokia E6, nějaké NAS krámy, multifunkční kraksna). Obvkyle mají nahozenu jednu ULA adresu a vedle toho IPv6 globální adreus od hlavního routeru (A). Bez problémů vybírají adresu a komunikujíé jak mají. Klyž hlavnímu routeru chcípne linka (nebo chcípne celý), tak záložní (B) začne propagovat svůj segment (řešeno s pomocí VRRPv6). Během pár sekund všemu naskočí i druhá globální adresa, takže mají ULA adresu, globální A (fakticky nefunkční), globální B. V té chvíli samozřejmě popadají spojení navázane přes global A, začnou se nabazovat nové, něco to zkusí rovnou z adresy B a jede, něco zkusí prvně A, když je jim to omláceno o hlavu nebo se nespojí, tak zkouší znova s adresou B.... Po nějaké době (mám preffered lifetime půl hodiny v RA), zahodí počítače A adresu a jedou už jen z B. Když router A a jeho linka opět ožije, zase zase propagovat on se ven a přejde to zpět na Ačkový segment... Provozováno rok.Pokud někoho zajímá, proč se nepropagují oba veřejné naráz, tak je to dáno nedodělky IPv6 v Mikrotiku, takže se tímto způsobem to ojebává (chybějící možnost ovlivňování priorit routerů a hlavně neexistující podpora pro policy routing IPv6).
Jinak výše popsané řešení je pro koncovou síť, třeba pobočkové nebo náročnější home uživatel pracující z domu a chtějící zálohovanou konekticitu. Jiná varianta pro IPv6 je použití ULA adres a překladu prefixů, což by bylo dfakticky NAT řešení z doby IPv4. Nicméně Mikrotik to nepodporuje.
Pro centrálu/velkou firmu je řešení vlastní blok, vlasatní AS a BGP ke dvěma partnerům (nicméně to má smysl jen s vlastním blokem /32 a žádným menším, jinak se zařadí do řady plačících, že jim IPv6 nefunguje). -
M. (neregistrovaný)
Pro IPv4 to funguje stejně. Jenom moc se nepodporuje u woken a podobných konfigurace víc IP dynamicky.
Je to dáno tím jak většina novějších aplikací dělá navazování spojení (nebo dneska je to už spíše schováno v knihovnách). Pokud používá getaddrinfo(),tak dostane pro danou cílovou adresu/jméno připraveny všechny varianty spojení a jen to ve smyčce zkusí. Dle lokálních preferencí pak může upřednostnit co chce. Takže stejná konfigurace pro IPv4, kdy mám víc IP adres od různých ISP se dá také použít, jen není tak běžná, zde je to běžněji řešeno tím NATem na bráně ven. -
To řešení přes DNS nefunguje, protože ačkoliv klient zkusí všechny kombinace, tak stále neví, kterou IPv4 adresu má použít jako zdrojovou. A pokud se trefí špatně (a když už se jednou trefí špatně, tak se trefí špatně vždycky, pokud nemá dostatečné informace v routovacích tabulkách, což nemá), tak mu provider ten paket zahodí.
(asi by stačilo nemotat cílové a zdrojové adresy dohromady a třeba bychom se domluvili)
-
M. (neregistrovaný)
Chci se spojit na adresu 1.1.1.1 (mimo mojí síť), zavolám an to getaddrinfo a ten mi vráti socket list, kde je připravneo spojení 2.2.2.2->1.1.1.1 a i 3.3.3.3->1.1.1.1, pokud lokální počítač má tyto dvě IP adresy (2.2.2.2, 3.3.3.3) na interfejsích, přes kterou to jde požadovaným směrem k 1.1.1.1, pokud budou mít stejnou metriku. Pokud místo IP použiji www.porno.net, tak dostanu případně v listu patřičně i struktury pro všechny možné IPv6 kombinace (včetně "blbostí" typu IPV4 mapped address) v závislosti na nastavneých preferencích OS (pokud si přes hinty některé věci nevynutím/nezakážu).
Na apliakci je pak jen zavolat v dalším kroku patřičně na ten socket list connect a čekat, která první z těch možností se chytne... -
Santiago (neregistrovaný)
1) C funkce getaddrinfo() nevraci seznam socketu, ale pouze seznam struct addrinfo, ktere obsahuji cilove adresy, ale nespecifikuji zdrojove adresy (viz RFC 3493). Mozna nejaka jina funkce dela to, co zminujes, ale AFAIK to rozhodne neni neco, co by aplikace bezne pouzivaly. Zdrojovou adresu obvykle vybira sitova vrstva OS.
2) Resit vyber 'spravne' zdrojove adresy tim, ze se postupne zkusi vsechny, je dosti zoufale reseni, nebot ne vzdy musi dojit k prijeti ICMP chybove zpravy (a v nejjednodussich pripadech k tomu nedojde) a tedy takove spojeni muze dlouho cekat na timeout.
-
Filip JirsákStříbrný podporovatel
Řekl bych, že pakety OSPF se nebudou bránit vstoupit na síťovou kartu koncového uzlu, služba upravující podle nich směrovací tabulky se také při spuštění na koncovém uzlu normálně rozeběhne. Pokud odmítáte použít jakékoli mechanismy pro řízení routování (ICMP, RA, OSPF), pak to opravdu asi budete muset řešit nějakým hackem. Já bych ovšem k problému dvojí konektivity raději hledal řešení, než abych vymýšlel obezličky, které přinesou spoustu dalších problémů. Zvlášť když IPv6 od začátku předpokládá, že zařízení budou mít více adres a že se bude používat autokonfigurace.
-
Pakety OSPF se nebudou bránit vstupu na síťovou kartu koncového uzlu, ale:
1. do koncových sítí se OSPF pakety neposílají, interfacy routerů jsou ve správné konfiguraci nastaveny jako passive (cisco terminologie), aby náhodou koncová stanice nemohla provádět podvratnou činnost, jako je třeba propagace různých sítí
2. na koncové stanici by musel běžet OSFP routovací démon, což opravdu není standardní situace (existuje něco takového pro windows?)
3. OSPF je link-state protokol a informace se vyměňují po navázání oboustranné komunikace router-router.Neodmítám použití mechanismů pro řízení routování, akorát říkám, že ten váš příklad s ICMP prostě nefunguje. To už je mnohem lepší ten příklad s getaddrinfo(), který by měl fungovat pro všechny komunikace navazované přes volání této funkce (což nemusí být vždycky pravda).
BTW: kdybyste správně sledoval vlákno, tak se od příspěvku kolegy "s" bavíme o 10.0.24.12, tj. IPv4 adresách.
-
Filip JirsákStříbrný podporovatel
Co přesně nefunguje na tom, že když zařízení obdrží ICMP Destination Unreachable, vyzkouší další záznam pro cílovou síť s nižší prioritou? Jak jinak má zařízení na takovou zprávu reagovat?
-
Co přesně by na tom mělo fungovat? Connect už byl proveden, takže IPv4 SAS už bylo resolvováno na nějakou IPv4 adresu. Takže bez další pomoci třeba pomocí toho getaddrinfo to už nemá co dalšího zkoušet. Jenomže i to getaddrinfo() bude fungovat patrně pouze na TCP spojení, takže budou věci, které nebudou fungovat protože fungují přes UDP (NTP a pod). Navíc budou teda fungovat opravdu jenom dobře napsané aplikace.
-
-
M. (neregistrovaný)
Kolega asi řeší případ, že spojení je již navázáno nějakou cesotu a daná cesta padne. Tak v případě multihomed sítí s různými IP pro různé cesty to spojení padne. V takovém případě samozřejmě není jiné cesty, než pro TCP (a obvkyle i UDP) spojení zahodit a zkusit otevřít nové, iterací přeš další možnosti získané z toho getaddrinfo.
Samozřejmě pro většinu běžného provozu je to asi akceptovatelné, když to nevypadává moc často (zkrátka kliknu reload na ten fejsbůk). Kde není a řešení vlastní AS a PI adresy je problematické, tak používáme to, že u našich apliací se používá SCTP protokol (jako náhrada za TCP/UDP) v režimu multihomed a přímo IP stack za mě drží spojení vícero cestami (např server má dvě IP a klient tkaé dvě IP, tka se naváží 4 kanály) a jen jeden je aktivní a když jim to nejde, tak sám IP stack to začne tlačit jiným, dostupným, bez ztráty dat a spojení dvou konců. Mechanismus přechodu na novou cestu je často i rychlejší, než u varianty PI adresy a vlastní AS. Samozřejmě to jde dělat jen tam, kd emám software pod kontrolou a potřebuji to.
Takže mechanismy existují. -
Filip JirsákStříbrný podporovatel
Případ již navázaného spojení doufám kolega neřeší, hned na začátku jsme se snad shodli, že to je případ, se kterým si ani všemocný NAT neporadí.
-
M. (neregistrovaný)
getaddrinfo samozřejmě funguje i pro UDP a případně i SCTP spojení. Je to jen o tom, že s tím ta aplikace musí být napsaná.
Jistě, pokud nějaká prehistorická apliakce jede svým starým stylem socket, connect, atd, tak má smůlu. Ale většina novějších už používá tento mechanismus (jak v unix, tak i ve windows světe existuje nějaký pátek), tak problém multihomed sítí i dual stack je tím elegantně vyřešen. Původně byl primárně určen k řešení automatického výběru IPv4/IPv6, ale řeší obecně možnost použít cokoliv, co daný stroj bude umět použít. -
Santiago (neregistrovaný)
Diskutujeme (IMHO) situaci, kdy koncove zarizeni je pripojeno do jedne site a az teprve ta sit ma dva ruzne uplinky (na hranicnim routeru ci routerech). V takovem pripade zarizeni ma jedno rozhrani a jednu nebo nekolik defaultnich rout. Diskutujeme IPv6, V takovem pripade:
1) o volbe spatne zdrojove adresy se zarizeni moc nedozvi, nebot zadnou ICMP zpravu dost mozna ani neobdrzi (technicky vzato totiz jde az o chybu pri snaze o doruceni odpovedi), takze chyba se detekuje az timeoutem.
2) I kdyby tu ICMP zpravu obdrzelo, tak ji nepouzije k oznaceni defaultni routy za nedostupnou, nebot nelze dost dobre odlisit duvody, ktere vedly k te ICMP zprave, a zda jsou relevantni k zvolene route/adrese.
3) V IPv6 neni silna vazba mezi pouzitou routou a zvolenou zdrojovou IPv6 adresou. RFC 3484 to moc neresi (az na pripad kdy zarizeni ma rovnou vic rozhrani), to chovani pro defaultni routy od ruznych hranicnich routeru zavadi az RFC 6724 z 2012-09. Nevim, kteri klienti to podporuji, ale vzhledem k novosti se na to asi neda moc spolehat.
4) Asi jedine spolehlive reseni je to, aby router s vypadlym uplinkem propagovat 'svuj' prefix s preferred lifetime 0, cimz se prislusne adresy stanou deprecated a nebudou pouzivany jako zdrojove pro nova spojeni. Nevim ale, zda takove chovani nejaky software podporuje.
-
M. (neregistrovaný)
Add 1] ano, tak se to chová, spojení se navazuje nekřesťansky dlouho, než první pokus vytimeoutuje a pak se zkouší druhé (pokud první linka jde do ztracena a chcípá to na timeout).
Add 4) Takto to mám uděláno pro IPv6 s dvěma routery. Když první ztratí IPv6 spojení, tak druhý začne propagovat svůj prefix a zároveň propaguje prefix prvního routeru s lifetime 0 a počítače od dalšího spojení už přejdou na nové adresy hned. Je k tomu použito VRRPv6, kdy proces routeru (a RA) je svázán s VRRPv6 rozhranním. Normálně ho drží první router a propaguje svůj segment (a zároveň propaguje segment druhého routeru s lifetime 0), když mu linka umře (testuje pingem), shodí si VRRP prioritu tak, že VRRP se překlopí na druhý router (takže první router zastaví posílání RA), tím pádem on pustí RA na VRRP rozhraní na druhém routeru, kde propaguje svůj segment a ten patřící prvnímu routeru s lifetime 0 a klienti na to reagují dle očekávání a od následujícího pokusu o spojení už jedou jen dle IP adres patřící k druhému routeru. Použity dva Mikrotik routery. NEdá s ena ROSu uděla,t aby v jendom segmentu se používaly naráz obě konektivity, protože ROS neumí pro IPv6 policy routing. -
M. (neregistrovaný)
Se obávám, že linux se jen přizpůsobil tomu, co nabízí i někteří jiní. Když nepočítam IPv6-IPv6 prefix translation (RFC6296), což j ejendo z možnáých řešení pro multi home sítě, tak některé renomované bedny umí NAPT i pro IPv6 (ať už 1:1 nebo 1:N). Uživatleé po tom řvou, tak to asi za peníze i dostnaou...
Někde jsme viděl přehled, kdo a co tkaového podporuje a linux v tom nebyl sám. -
Ondřej CaletkaZlatý podporovatelS IPv4 bych to tak samozřejmě neviděl: No new IPv4 Provider Independent (PI) space will be assigned.
-
Filip JirsákStříbrný podporovatel
I když ve stejné podsíti bude jen zařízení ISP, pořád to podle mne není "nikdo". Druhý problém je, že do NATu se díry dělají automaticky, podle toho, jak se implementace snaží uhodnout, že se jedná o nějakou komunikaci, pro kterou je potřeba udržovat "spojení". No a protože se z principu jedná o věštění z křišťálové koule, nikdy se nedá vyloučit, že se někomu nepodaří tu křišťálovou kouli nějak ošálit. Někdy může stačit odeslat paket se zdrojovou adresou z vnitřní sítě, někdy to může být o dost komplikovanější. No a pak taky samozřejmě hrozí, že tu díru v NATu otevře jediným paketem kterýkoli počítač ve vnitřní síti.
O tom, že NAT může být překážkou, myslím nikdo nepochybuje -- ostatně právě to je problém NATu. Jde o to, že pokud to někdo s bezpečností myslí aspoň trochu vážně, stejně musí nakonfigurovat firewall. A měla by to být samozřejmost, zvlášť když konfigurace firewallu je snazší, než konfigurace NATu.
-
fik (neregistrovaný)
nepustit nikoho dovnitř není problém, problém který je spojený s NATem je pustit dovnitř ten chtěný provoz.
jinak řečeno co když by jste se naopak chtěl na svůj počítač dostat pomocí telnetu (ano že je telnet špatný nápad je jasné)? tak třeba SSH, HTTP(s),... už chápete? jasně port forward... ale co když chcete mít víc web serverů? s jednou, nebo jen omezeným počtem veřejných IPv4 adres, začíná sebevražda zvaná nestandardní porty.
v tom je kouzlo globálních IPv6 adres, jejich platnost a dostupnot odkudkoli.
a těch případů bude přibývat, kdo by odolal "internet of things" :)
a to že je bezpečnost složitá? ano může být, tak někomu zaplatím za zabezpečení, u bytu to dělám také,... -
xyyyzzzz (neregistrovaný)
Spojenie bude typu klient-server, klient sa pripaja na konkretny port na servery a pre spatnu konekciu sa otvori port a fw tuto spatnu konekciu povoli na zaklade pravidla ESTABLISH, RELATED za predpokladu ze je ESTABLISH a RELATED povolene. Takze nebudeme tam kde sme teraz z natom. Nakolko rovnako by spojenie fungovalo aj priamo bez firewallu...
Ak bude potrebne inicializovat spojenie z internetu, tak si pouzivatel jednoducho povoli fo fw dany port, rovnako ako si teraz nastavuje presmerovanie portu...
-
Pavel Trefný (neregistrovaný)
Přeně tak, uživatel si upraví firewall podle sebe a je to. Nikde také není řečeno že uživatel si nemůže nastavit firewall na svém koncovém zařízení. V takovém případě je zrušení stavového firewallu to nejmenší.
Jako výchozí rešení, kdy ne každý uživatel vůbec tuší že by se měl nějak chránit je to podle mě dobré. -
Ondřej CaletkaZlatý podporovatel
Já věřím, že časem zase dospějeme do stavu, kdy bude firewall buď na koncovém zařízení, nebo vůbec, jako to kdysi bývalo. Jak může kdokoli za mým počítačem vědět, které služby chci provozovat a které ne?
Do té doby, než k tomuto poznání dospějí všichni, vymyslel jsem rozumný kompromis − propouštět dovnitř provoz na adresy, které mají mezi 64. a 95. bitem nuly (číslováno zleva a od nuly). Tím jsou ze hry všechny autokonfigurované adresy, takže kdo chce přijímat venkovní spojení, nechť si ručně nastaví krátkou IP adresu, např. 2001:db8:dead:beef::abcd:ef. Ostatně, pokud chce někdo přijímat spojení z Internetu, prevděpodobně chce i nějakou krátkou a snadněji zapamatovatelnou adresu.
-
Filip JirsákStříbrný podporovatel
Já věřím, že časem dospějeme do stavu, kdy bude volitelně firewall na rozhraní sítí – a bude tam řešit útoky na síťovou infrastrukturu (pokusy o zahlcení linky, podvržené pakety apod.), případně bude chránit vybraná zařízení (servery, pračky :-) atd.). Na stanici pak nebude žádný firewall, protože zda a jak má nějaký software komunikovat v síti půjde nastavit v tom softwaru.
-
Filip JirsákStříbrný podporovatel
To, že v základní instalaci není spuštěn žádný server, není věc zdravého rozumu koncového uživatele, ale zdravého rozumu dodavatele operačního systému.
-
Sob (neregistrovaný)
Klient-server problem neni. Ale ja si chci s prateli vymenovat instalacky Linuxu pres P2P, posilat naprimo soubory pres Jabber a podobne. :) A to s routerem, kterej blokuje prichozi pripojeni, neni uplne ono. Ja si porty povolim, ale vetsina normalnich uzivatelu nic takovyho nikdy delat nebude. Jeste tak kdyz jim ve Windows vyskoci, ze by program chtel na net, tak to odklepnou, ale router je takova divna vec kdesi daleko, do ktery nepolezou. Takze standard bude takovej, ze na jednoduchy primy pripojeni nebude spoleh, coz je prave velmi podobny tomu, co mame dneska s NATem.
-
Palo M. (neregistrovaný)
Ziadna bezpecnost. Za to moze prave NEbezpecnost. Koncove stanice (hlavne Windoze) mali tradicne ubohe zabezpecenie (najprv ziaden firewall k dieravemu systemu a neskor plno roznych firewallov rozdielnej kvality obvykle ponechanych v pazuroch neskusenych uzivatelov)... Tak sa firewall dal na router, tam kde je aj NAT (vacsina domacich routrov s ktorymi som prisiel do styku naozaj ma okrem NATu aj jednoduchy firewall). Pragmaticke riesenie, ktore vo vysledku len legitimizovalo bordel na koncovych staniciach (kvaziargumentom "ved to je zabezpecene").
Ja mam doma na vsetkych koncovych strojoch firewall nastaveny tak ako ja chcem a potrebujem, kazda masina chrani sama seba svojim vlastnym firewallom, takze na routri mi staci iba minimalny IPv6-firewall (v podstate len ochrana pred falsovanim vnutornych adries zvonka, ale ziadne filtrovanie normalnej prichodzej premavky). Lenze ak by sa taketo nastavenie routra standardne pouzivalo pre beznych ludi, ktori maju firewally na koncovych strojoch bohvieake (a mozno ziadne), pravdepodobne by to skoncilo bezpecnostnou katastrofou (boli by zombici aj tam, kde dnes nie su).
Takze bohuzial, pokracuje sa v pragmatickom rieseni, ktore sice ma pozadovanu bezpecnost, ale zaroven je aj velmi obmedzujuce. Kym v IPv4 bol obmedzenim uz samotny NAT (takze restriktivny firewall na routri neobmedzoval uzivatela viac nez NAT), v IPv6 je restriktivny firewall na routri uz jedine obmedzenie (ale pritom uz to obmedzenie nie je nevyhnutne).
Takze sa skor da suhlasit s tvrdenim "tomu nas naucil NAT" nez s tvojim "bezpecnost je bezpecnost". Aby som to upresnil: Technologia NAT samotna samozrejme za nic nemoze. Ale na obmedzenia vyplyvajuce z jej masivneho nasadenia si ludia v priebehu rokov vacsinou uz zvykli - ty sam si jasnou ukazkou toho, ze "ti to nevadi" a dokonca to obhajujes (vraj je to v zaujme bezpecnosti). Ale nie vsetci sme si na to zvykli... (a na ten tvoj argument sme zareagovali, pretoze je podla nas nespravny) -
Palo M. (neregistrovaný)
Nikdy so netvrdil, ze "NAT mi firewalluje" a taketo slovne spojenie mi nedava zmysel. NAT predsa robi len preklad sietovych adries (ako uz jeho nazov napoveda), takze nic "nefirewalluje" a uz vobec nie mne. Takto postavena otazka je nezmyselna a neda sa na nu odpovedat.
Akurat som povedal, ze NAT _obmedzuje_ uzivatela, a to tvrdim aj nadalej (konkretne priklady obmedzeni uz spomenuli ini, aj v tejto diskusii, napr. Sob vyssie). -
Jenda (neregistrovaný)
„Nikdy so netvrdil, ze "NAT mi firewalluje" a taketo slovne spojenie mi nedava zmysel.“
Jejda, omlouvám se, myslel jsem samozřejmě firewall.
Šlo mi o to, že třeba já nemám na desktopu žádné služby, které by si FW zasloužily. Buď mi poslouchají jenom na lo (webserver, na kterém vyvíjím web, mysql) nebo poslouchají ven, ale pak chci, aby poslouchaly - třeba Jabber přenos souborů.
-
SB (neregistrovaný)
U Ipv4 se MUSÍ lézt na router, protože se tam musí nastavit NAT (protože pouze tam se musejí překládat adresy/porty), ale určitě se tam nemusí lézt kvůli tomu, abych nastavil fajrák! Takže jak bylo psáno výše, nikdo neříká, že se frewall nemůže přesunout z routeru čistě na koncové zařízení (pýsydlo)! Firewall se na router umisťuje proto, aby se v jednom místě vyřešilo 10 lojzů, kteří si ten firewall nastavit neumějí. Není problémem ten firewall na routeru (či ktekoli jinde po cestě) vypnout a říct koncovému uživateli „dělej si s tím, co chceš“. Takže to jsou zcela rozdílné koncepty - NATu je uživatel vždy podřízen, kdežto odpovědnost za provoz (firewall) je možno přesunout KAMKOLIV po cestě.
-
Dle RFC je vhodne davat na Point-To-Point linky prefix /127. Vyresi to mnoho problemu se zatezi routeru skenovanim. Bohuzel Mikrotik podporuje maximalne /126. Doufam, ze se to zmeni. Zatim je na spouste zarizeni, ktera podporuji IPv6 problem s takovymto prefixem, treba Fortigate. /64 je fajn pro lokalni sit, ale pro providerovske PtP linky je mnohem vhodnejsi /127.
-
Santiago (neregistrovaný)
> Dle RFC je vhodne davat na Point-To-Point linky prefix /127.
Ktere RFC?
> Vyresi to mnoho problemu se zatezi routeru skenovanim
???
Jinak na ptp linky mezi routery providera je mozne vubez zadny prefix nedavat, routovani muze jet pres link-local adresy (a OSPFv3 to tak standardne dela).
-
Ondřej CaletkaZlatý podporovatel
No, ony existují dvě RFC, první, dnes již historické, se jmenuje Use of /127 Prefix Length Between Routers Considered Harmful, zatímco nové se přesně naopak jmenuje Using 127-Bit IPv6 Prefixes on Inter-Router Links.
To starší RFC prefixy délky 127 odmítalo z důvody anycastové adresy routeru, která obsadila jednu ze dvou možných adres a to mohlo způsobovat problémy (to je možná důvod, proč to Mikrotik zatím nepodporuje). Novější RFC zase /127 prosazuje zejména z důvodu zabránění ping-pong útoků, kdy někdo pošle paket na jinou adresu než ::1 nebo ::2 a pokud to bude PtP linka, paket bude stále zvonit sem a tam, než mu vyprší TTL. Pokud to bude ethernetový spoj, tento problém nehrozí, ale zase tu máme problém s vyčerpáním prostředků pro objevování sousedů na straně routeru.
Nové verze routerů by ale proti těmto útokům měly být chráněny tak, že nepošlou paket po stejné PtP lince, po které přišel a dávají menší prioritu hledání dosud neznámých sousedů, takže by mělo být vcelku jedno, jestli se pro propojovací sítě použije /64 nebo /127 nebo cokoli jiného, nebo jen LL adresy.
-
mathew7 (neregistrovaný)
To by ma zaujimalo kolko maju poskytovatelia v EU este volnych ip adres ;) ipv6 mi pride strasne tak ako keby nanutena, i ked za nejaky cas sa stim budu musiet viacmenej vsetci vysporiadať ak budu chcieť aj naďalej poskytovať služby...
Ináč ak sa nemýlim ten tunelling ipv6 funguje nad ipv4, zapuzdrený paket si ide cez ipv4 sieť.. ? :) -
Pavel Trefný (neregistrovaný)
Jeste k poctu IPv4 adres v EU, zatim jich poskytovatele maji nasysleno dost, takze nejaky cas vydrzi, ale problem s dochazejicima adresama a IPv6 je mnohem hlubsi. Je treba se na problem nekoukat jen ze strany, ja mam adres dost a me se to netyka coz dela treba nase konkurence, ale i zdruheho konce. Je treba si rict ze v regionu asie pacifik IPv4 nejsou uz dlouho a co udela poskytovatel, kteremu dojdou adresy a bude potrebovat nejak zviditelnit svuj obsah ? Hodi sve servery na IPv6 a v tom to je. Takze i kdyz poskytovatel v evrope bude mit IPv4 hafo, tak bez IPv6 u zakazniku se na zdroje, ktere jsou pouze v IPv6 proste nedostane.
Prikladem je treba http://www.nebezi.cz -
Ondřej CaletkaZlatý podporovatel
Problém je, že v Asii-Pacifiku rozvoj IPv6 za poslední rok spíše stagnuje, jak psal ve své zprávě Geoff Huston z APNICu.
Prostě všechny masové služby se už řadu let budují jako server-klient a počítá se s NATy po cestě, protože je to zatím levnější. Můžeme jen doufat, že se to časem změní.
Osobně denně používám spoustu IPv6-only služeb, protože je to jednodušší, než pouštět různé VPNky a řešit kolize privátních adresních rozsahů. Kéž by k takovému poznání došlo více lidí a mohli tak vytvořit skutečnou poptávku po IPv6.
-
j (neregistrovaný)
Neni ak uplne pravda, trebas torrenty - na spouste trackeru se da vpohode dostat na pomer 1:1 (ipv4/6 peers), a provozovatele IPv6 vylozene tlaci. Zaroven je to vyhodne i pro uzivatele, jsou totiz pak "active" => nemusi cekat, az se do swarmu zapoji nekdo, kdo jim zprostredkuje ziskani toho, co chteji.
Me osobne se trebas na IPv6 libi to, ze si muzu pustit trebas 20 http(s) webu, vsechny na standardnim portu, s odpovidajicim certifikatem ... a nemusim resit ruzny zhuverilosti kolem toho, jak to zprovoznit na jedine IPv4.
-
Ondřej CaletkaZlatý podporovatel
Me osobne se trebas na IPv6 libi to, ze si muzu pustit trebas 20 http(s) webu, vsechny na standardnim portu, s odpovidajicim certifikatem ... a nemusim resit ruzny zhuverilosti kolem toho, jak to zprovoznit na jedine IPv4.
Tuhle výhodu trochu kalí skutečnost, že na takový IPv6-only server se skoro nikdo (z reálných uživatelů) nedostane :P.
-
„S implementací IPv6 na MikroTiku jsme nenarazili na žádný problém a vše funguje dle našich představ“
Chtěl bych mít takto benevolentní představy o fungování IPv6 routeru.
Podpora IPv6 jako doplňku IPv4 v Mikrotiku docela funguje. Občas se objeví nějaký problém především v některém z nastavovacích rozhraní (včetně command line). Leccos se už vyřešilo. Ale vytahovat se v roce 2012 s routerem který neobhospodaří IPv6 síť mi přijde trochu pozdě.
Až jednou budete chtít vypnout IPv4 a přejít na řešení typu NAT64, tak budete ještě rádi, když to Mikrotikové do té doby vůbec dodělají a doladí.
Podrobnější informace z testu IPv6 na Mikrotiku se zaměřením na koncové sítě:
http://www.abclinuxu.cz/blog/pavlix/2012/9/mikrotik-ipv6-a-dobry-obed
Pro kulturní referenci ohledně oběda v názvu blogpostu doporučuju:
-
Ondřej CaletkaZlatý podporovatel
GPL je u Mikrotiku nahouby hlavně proto, že si ten jejich systém nemůžete sami opravit.
BTW: Gratuluji SporkNetu k získání IPv4 přídělu :)
-
Pavel Trefný (neregistrovaný)
NAT64 je cesta do pekel, k fungovani potrebujete dns nazev aby to fungovalo. A pro priklad treba skype jmena pro adresovani nepouziva. Cili se stane to ze aplikace se odkaze na ipv4 adresu a na pocitaci kde ipv4 vubec nemate je to celkem problem.
Da se to sice obejit aplikaci na koncovem pocitaci/zarizeni , ale uzivatelsky je to znacne obtezujici. Jedina spravna volba je v soucasne dobe dual stack. -
Ondřej CaletkaZlatý podporovatel
NAT64 je skvělá technologie, ale protože na ní nefunguje Skype, je v současnosti nepoužitelná :)
Co se teď vyvíjí v Cisco a co může být imho velmi zajímavý způsob nasazení IPv6, je protokol MAP46. Je to taková variace na DS-lite, až na to, že nemá žádný CGN, místo toho dostane každé CPE staticky veřejnou adresu a část portového rozsahu (jiná část patří jinému zákazníkovi).
Přístupová síť providera je tedy celá IPv6 only, uživatel doma za CPE má normální NATované IPv4 adresy a někde v core providera sedí velká bedna, do které vede IPv4 internet a ta jej na základě adresy a portu posílá na správnou IPv6 adresu CPE.
-
„NAT64 je cesta do pekel“
Tento názor nesdílím. A ve vašem příspěvku jsem nenašel jediný validní argument. Můžem se někdy sejít a popovídat o tom, jak NAT64 skutečně funguje a jak se používá. NAT64 poskytuje prakticky to samé, co IPv4 NAT, tudíž by z vašich tvrzení vyplývalo, že i ten je stejně nepoužitelný.
-
Santiago (neregistrovaný)
> NAT64 poskytuje prakticky to samé, co IPv4 NAT, tudíž by z vašich tvrzení vyplývalo, že i ten je stejně nepoužitelný.
Pokud spravne rozumim tomu, jak funguje NAT64, tak co se tyce IPv4 mi to prijde podstatne vic omezujici nez klasicky IPv4 NAT. NAT64 (v kombinaci s triky s DNS) funguje pouze v tom nejtrivialnejsim pripade, kdy klient si pres DNS zjisti IP adresu serveru a na nej se pripoji. V pripade, kdy cela komunikace zahrnuje vice akteru (napr. ruzne ptp site), tak je zde rozdil - u klasickeho NATu nefunguji pouze spojeni na klienta, u NAT64 ani na kohokoliv jineho (jine servery, ptp klienti s verejnou IP adresou), jehoz IP adresu se klient dozvi uvnitr protokolu.
Krom ruznych PtP protokolu (kdy se klient dozvi z 'trackeru' verejne IP adresy ostatnich 'aktivnich' peeru), by problem mohl nastat i u HTTP ci SIP redirectu (pokud v redirectu bude pouze IP adresa, coz bych treba cekal u tech SIP redirectu u SIP registraru).
-
Ondřej CaletkaZlatý podporovatel
Všechny tyto problémy je možné řešit mezivrstvou na klientovi, která provede přeložení IPv4 soketu na IPv6 soket, takže začnou fungovat i aplikace, používající IPv4 literály. Takhle třeba funguje WrapSix client. Co chybí, je nějaká signalizace, která klientovi řekne, že v dané sítě funguje NAT64 a že NAT64 používá takový a takový prefix, aby se podle toho tato mezivrstva mohla zařídit.
-
Santiago (neregistrovaný)
No, IMHO kdyby se s necim jako NAT64 pocitalo od zacatku IPv6 (tedy by takova prekladovat vrstva byla povinnou soucasti IPv6 stacku a fungovala by bez jakekoliv konfigurace na vyhrazeny prefix), tak by to byl vyborny prechodovy mechanismus, ale pokud to vyzaduje bud dodatecny klientsky software, nebo hacky v DNS, tak je to pouzitelne mozna v podnikovych sitich, ale pro normalni ISP dost neprijatelne reseni. To uz spis DS-Lite nebo vyse zminovany MAP46.
-
Santiago (neregistrovaný)
V cem je pro ISP lepsi NAT64 nez treba DS-Lite? V obou pripadech ma IPv6 only sit, ale musi provozovat nejaky centralni stavovy NAT.
Mne z pohledu ISP prijde jako nejvyhodnejsi vyse zminovany MAP (viz http://tools.ietf.org/html/draft-ietf-softwire-map-02 ), protoze pro ISP resi jak prechod na IPv6, tak akutni nedostatek IPv4 adres a zaroven odpadaji prakticky vsechny problemy s centralizovanymi stavovymi NATy ci dvojitym NATovanim (uzivateluv router a centralni NAT u poskytovatele).
-
chaser (neregistrovaný)
Jen tak na okraj bych chtel rict, ze me ted v souvislosti s IPv6 Cesi a Slovaci opet prijemne prekvapili. Hledal jsem na torrentu jednu archivni zalezitost z dob davno minulych, protoze originalni instalacni media se po letech ukazala jako nepouzitelna. Zatimco na zahranicnich trackerech meli vsichni peerove az na jednu jedinou vyjimku IPv6 adresu z rozsahu 2001::/32 (Teredo), na CZ/SK trackeru jeli pres IPv6 4 z 22ti peeru , coz je myslim docela pekne.
-
Ondřej CaletkaZlatý podporovatel
A kolik z nich mělo adresy z rozsahu 2001:470::/32 (HE.net) a 2a01:8c00:ff00::/40 (SixXS PoP IGNUM)?
-
Na druhou stranu co je komu do toho, jakým způsobem si zřídím kontektivitu. Teď nemyslím různé automatické tunely, 6to4 apod, ale podle mě je konfigurovaná konektivita přes nějakého providera (třeba SixXS PoP IGNUME) stejně legitimní přípojkou jako ethernet.
To bys mohl začít počítat, kolik IPv4 trafficu probíhá přes různé tunely, redirecty, L4/L7 reverzní proxy, aniž by se to nějak projevilo. Nebo by se ti nemusel líbit třeba transport po PPP tunelu a tím vyškrtneš (nejen) všechny ADSLkaře.
-
Ondřej CaletkaZlatý podporovatel
Ano, to nerozporuji. Taky mám na dvě ze čtyř míst zavedeno IPv6 tunelem k naprosté spokojenosti. Jen jsem chtěl poukázat na to, že to, že se v ČR nepřipojujeme Teredem nebo 6to4 nemusí nutně znamenat, že je u nás IPv6 nějak zázračně rozšířena.
-
Santiago (neregistrovaný)
Pro mne je menecenny, nebot vede k suboptimalnimu routovani (oproti tomu PPPoE tunel u ADSL v podstate kopiruje fyzickou topologii). I kdyz je pravda, ze pokud je PoP pripojeni do NIXu se zanedbatelnou latenci, tak uz to moc nehraje roli.
V nekterych pripadech je takovy konfigurovany tunel horsi nez 6to4, protoze pri komunikaci ruznych uzivatelu 6to4 bude provoz take kopirovat fyzickou topologii.
-
Ondřej CaletkaZlatý podporovatel
Přesně tak, nezáleží na technologii, jako spíše na délce okliky. Z toho pohledu jsou tunelovací servery zapojené v CZ-NIXu poměrně plnohodnotné, až na spojování na krátké vzdálenosti (např. v rámci jednoho ISP).
6to4 je z hlediska routování výborné, bohužel to zabíjí nedostatečná podpora 6to4 na straně poskytovatelů obsahu a nejistá funkčnost veřejných 6to4 bran (mají různé MTU, občas zahazují fragmenty či jiné pakety, které se jim nelíbí, atd.).
