Vlákno názorů k článku IPv4 jako služba aneb jak síť zbavit dual-stacku od Ray - Jak už někdo poznamenal, V6 je špatně od...
-
Ray (neregistrovaný)
Jak už někdo poznamenal, V6 je špatně od samého počátku a idálně neměl, v takovéto podobě, vzniknout. Sice V6 nějak moc nesleduju, ač siťařina patří k mojí práci, myslel jsem, že mne u něj zas tak moc nepřekvapí. Ale vždy se najde nějaká šílená obezlička "aby to fungovalo", které překvapí. Co naplat, že to není kompatibilní tady, tamhle a onde. Co naplat, že to rozbije DNSSEC (pokud jsem to správně pochopil, kdyžtak mi to někdo pls vysvětlete, jak to s tímto pojede, neb pokud podepisuju jen V4 a očekávám V6). Důležité je jen to, že ta ten šílenej kočkopes bude fungovat :) A když ne, vymyslíme tunel a překlad ještě tunelovější a ještě překladovější než všechny ostatní (o: Haleluja !
R.
-
DNSSEC samozřejmě s IPv6 normálně funguje. Například tady na Rootu jsou pochopitelně AAAA záznamy podepsané, stejně jako všechny ostatní.
O komplikovanosti IPv6 mluví obvykle ti, kteří to ve skutečnosti nikdy neviděli. Naopak v šestce je spousta věcí jednodušších a moc pěkně navržených. Ano, má to některé mouchy, ale není to taková tragédie, jak se snaží občas lidi prezentovat v diskusích. Doporučuji si alespoň zkusit v některé síti IPv6 rozjet.
Já mám šestku všude a jsem s ní naprosto spokojený.
-
Ray (neregistrovaný)
Ten tunel zpřístupňuje V4 do V6. Takže se nedá předpokládat existence AAAA záznamu. Na to jsem narážel. Ne na samotnou existenci DNSSEC na V6. To snad bylo z toho postu jasné...
No, jestli jsem ji viděl nebo ne, to nevím. Vždy to bylo jen virtuání (o: Stack jsem na ni psal, do malých embeded zařízení, stejně tak jako pro 4ku, takže z praktického hlediska s ní nějakou zkušenost mám... Proto nám všechno jede na V4, bez výjimky.,,, Na úrovni o které píšeš, funguje (asi obvykle) bezproblémově. Stačí si dohledat diskuzi snad skoro pod každým článkem V4 x V6 :) Mne naopak přijde, že všichni její zastánci předpokládají, že každé zařízení má tuny MHz, tuny RAM, ... Ale reálné věci, které ovládají chod strojů, na kterých jsme zavislý, obvykle tyto vymoženosti nemají. Ba dokonce se často ani nepoužívá linux (ikdyž to ma kapacitu), nebo jinej velkej OS/kernel. Prostě už jen protože jsou to miliony řadek, kde se může něco rozbít. A mit 20K něceho, nebo milion jiných ? To je jen otázka míry pravděpodobnosti chyb.
Co by si byl radši, kdyby v rozvodně, díky který mas elektriku, bylo PLC s nějakým "mini" softem nebo (jakejkoliv) kernel s milionama řádek ? CPU vyráběnej supr-dupr-skoro-nano technologií, nebo šváb co má hradlo 10ti násobně širší a díky tomu přežije "věky" ? (o ESD, přepěti a pod nelmuvě, tyhle věci nelze nikdy uplně odfiltrovat).
V6 nebyla evoluce, ale revoluce, kde si každej chtěl prosadit něco svého. Proto to dopadlo jak to dopadlo a ještě poměrně dlouhou dobu se nic nezmění. Jen můj názor, nic víc nic míň. A ještě pěkných pár let budou lidi řvát, jak je V6 skvělá, lepší, nejlepší, jen proto, aby tomu ostatní uvěřili.
R.
-
Ondřej CaletkaZlatý podporovatelCo se týká DNSSECu a DNS64, tak kompatibilita je zajištěna. Validace se dá provádět ještě před DNS64. Pak musí být mezi DNS64 a klientem bezpečný kanál. Druhou možností je, že si validaci bude dělat klient přímo u sebe, pak si musí u sebe dělat i DNS64, což by si měl objevit pomocí RFC 7050, stejně jako CLAT zmíněný v článku.
-
Ray (neregistrovaný)
Takže už nemohu validovat sám, ale pouze přesouvám důvěru "kamsi" - k tomu poskytovateli. A to podle mně podráží princip DNSSEC, který vnikl, abych *já* jako klient měl jistotu, že můj dotaz je nepodvržen. Ale dejme tomu, že poskytovatelovi věřím. Jak udělám "tunel" pro DNS ? Pokud nemám po cestě nějakou krabici (co to uděla transparentně), ale mám jen třeba NTB a podobně, tak standarně to není zas tak snadné. Alespoň mně nenapadá, jak to udělat např. s Widlema bez podpory další aplikace (to neznamená, že to nejde, jen to třebas nevím)... A to je celé jadro podobných obezliček. Je to jako alopati versus jiné přistupy. Neřeší příčinu, jen zalepují následky příčiny...
R.
-
Ondřej CaletkaZlatý podporovatel
Přečtěte si prosím znovu příspěvek, na který reagujete. Validaci si samozřejmě sám dělat můžete, jen se pak předpokládá, že si i sám uděláte DNS64.
A propos, zkoušel jste takovou validaci na vlastním stroji provozovat? Speciálně ve spojení s forwardováním na DNS resolver ISP dochází často k poměrně nepříjemnému drhnutí, na které si třeba často stěžují uživatelé routerů Turris.
-
„A propos, zkoušel jste takovou validaci na vlastním stroji provozovat? Speciálně ve spojení s forwardováním na DNS resolver ISP dochází často k poměrně nepříjemnému drhnutí, na které si třeba často stěžují uživatelé routerů Turris.“
Můžeš to nějak upřesnit a pokud možno mě kontaktovat i mimo root? Fedora (či jiná distribuce, kde se to umí) s instalovaným dnssec-triggerem aktivně testuje DNS servery ISP a v případě, že nepředávají záznamy potřebné pro DNSSEC používá server, který s DNSSEC funguje.
-
Ondřej CaletkaZlatý podporovatel
Jedná se o problém s validací žolíkových domén, když je forwardováno na BIND<9.9.0. Více na http://wildcarddnssec.jdem.cz a offline.
-
M. (neregistrovaný)
Požadovanou funkcionalitu, že validaci dělá nadřazený DNS server a Windows jako klient si k němu udělají zabezpečené spojneí pro zajištění důvěryhodnosti, tak tu Windows umí od verze 7. Je to na 2 kliknutí myší. :-)
Windows 7 totiž obdsahují nevalidujícícho DNSSEC forwardujícího klienta, který sám validaci nedělá, ale umí od nadřazeného převzít informaci o tom, zda validace DNSSEC proběhla OK nebo záznamy byly bez DNSSEC. Proto ten poslední hop zabezpečuje pomocí IPsec transportu, aby se zabránilo manipulaci po cestě od validujícího DNS serveru ke klientu.
Jiná věc je, že to moc neumí ty DNS servery, pokud to není Windows 2008 a novější server. :-(
Nastavení viz "Name Resolution Policy Table". -
„Validace se dá provádět ještě před DNS64.“
Pokud vím tak aby DNSSEC poskytoval nějaké zabezpečení, je potřeba důvěřovat validujícímu DNS serveru, což lze v praxi typicky jen pokud běží validující DNS server na localhostu. Z toho důvodu je řešení, které navrhuješ, debilní.
Já osobně už jsem před delší dobou navrhoval toto řešit tím, že se použije vždy obecně známý DNS64 prefix a klient použije validační data IPv4 i pro IPv6.
-
Ondřej CaletkaZlatý podporovatel
Jenomže obecně známý prefix NAT64 se například nesmí použít pokud se pomocí NAT64 připojuješ k RFC1918 adresám. Plus hromada dalších důvodů, proč může někomu vyhovovat provozovat NAT64 na svém prefixu (testovací instalace v go6lab je jeden z nich).
Podle mě je DNS server na localhostu naprosto v pohodě, stačí do DNSSEC-triggeru přidat detekci PLATu podle RFC7050 a vývojáře unbounda dokopat k podpoře DNS64 v upstreamu (patche jsou v projektu Ecdysis a zdají se být funkční). Při tom kvantu věcí, které DNSSEC-Trigger dělá už teď, by se klidně mohl postarat i o toto.
-
Ja tomu fandim. Ma sanci to zabit duveryhodnost DNSSEC coz je prvni vyznamny hrebik na ceste zbavit se DNS jako takoveho. Tim spis, kdyz to nad IPv6 neprinasi nic vic nez zduplikovani "trustee". i kdyz to se muze nekomu hodit na delegaci roli.
Uz jen aby nekdo implementoval nejakou uzasnou ficuru pod rouskou kompatibility a jako spravny MIM utocnik podepisoval na tom tunelu vsechno co prijde a prevede ze ctverky a podstrkaval to klientum v sestce. -
Tak tyhle ipv4 kontrolery by snad nebyly problem. Kdyz se z ipv4 podari vystrnadit domaci uzivatele s porne, fejsbuckem a mailem, budete mit na kontrolery cely ipv4 rozsah a tolik tech zarizeni snad hned tak nebude, aby to nestacilo. Celkem nevidim duvod, proc do podobnych zarizeni rvat ipv6. I kdyby uz neexistovala zadna konektivita po ipv4 skrz Internet, porad si to muzete nejak protunelovat. Tak jako tak tyhle veci asi nevisi rovnou na verejne ip, aby si s tim hrali crackeri, ale za poradnym firewallem, VPN a co ja vim.
-
Ray (neregistrovaný)
Je to jen otázkou pohledu. Z pohledu poskytovatele služeb a správce tuny "krabiček" prostě nemám jedinný důvod pro V6ku. Naopak vše jen kompikuje. Pokud by se nešlo revolucí, neměnila se tuna věcí a nepřidávaly se zbytečnosti, bylo by to určitě jiné. Na začátku vyhrála loby, ne smysl pro funkčnost systému. Nemá význam opakovat co je skoro pod každým podobným evangelickým článkem :)
R.
-
Ondřej CaletkaZlatý podporovatel
A stejně tak se pod každým podobným článkem opakuje otázka: „Jak chcete rozšířit adresní prostor a přitom zachovat kompatibilitu?“
Jasně, můžeme se bavit o tom, že princip RA, SLAAC, EUI-64, DHCPv6, atd. je špatně, že se mělo radši 1:1 převzít to, co fungovalo v IPv4, ale stejně bychom měli dva nekompatibilní světy, pro které bychom museli stavět přechodové mechanizmy.
-
IPv6 rozhodně není špatně od začáttku. V základu je navržené velmi pěkně a řeší dost neduhů IPv4, nejpalčivější je možná TCP window size.
Problémem IPv6 je halda sraček které tam před 15ti lety nakakali odtržení teoretici na univerzitách, ve snaze panelově vyřešit všechno od VPN přes mobilitu. Halda naštěstí trochu zatuhla, část hovínek se oddrolila ještě před masovým nasazením, o časti děláme že ji nevidíme a do těch míst nešlapem, já vnímám jako největší problém RFC6177 a spol, viz můj post výše.
Osobně věřím jen na dual stack, tyhle obezličky vyvolávají jen další problémy k řešení vyvolávají disproporce na síti a nemají smysl. Protože přechod nespěchá, má cenu spíš postupné řešit pořádný dualstack.
-
Ray (neregistrovaný)
S tím se nedá prakticky nic jiného než souhlasit, s výjimkou začátku, V6ky kde by možná bylo lepší nejít novým formátem paketu, ale rozšířit header existujícíma možnostma V4ky. Ale i to ma své nevýhody. V každém případě, zařízení, která by uměla předávat tyhle headery by mohla podporovat V6ku automaticky, což je, zcela logicky, nechtěná featura, že... Už jen to, že IPSEC bylo mandatory pro V6ku. To ukazuje na to, jakej typ lidí to sestavoval...
R.
-
Filip JirsákStříbrný podporovatelTo vaše „řešení“ se objeví pod každým článkem o IPv6. Opravdu má své nevýhody – všechny nevýhody IPv6, a jako bonusovou nevýhodu navíc to, že by to velmi zpomalovalo páteřní routery. Stejně byste měl dva nekompatibilní světy, IPv4 a IPv4 s rozšířením. Oproti současnému stavu by navíc docházelo k problémům, kdy byste IPv4 paket s rozšířením poslal zařízení, které by tomu rozšíření nerozumělo.
-
Ondřej CaletkaZlatý podporovatel
Osobně věřím jen na dual stack, tyhle obezličky vyvolávají jen další problémy k řešení vyvolávají disproporce na síti a nemají smysl.
Hlavní problém dual stacku je, že všechno je potřeba konfigurovat, dohledovat a troubleshootovat dvakrát. A zejména ten troubleshooting bývá oříšek i pro zkušené techniky, pro BFU volající na zákaznickou podporu jde o v podstatě neřešitelný problém.
Například: IPv6 konektivita funguje, ale setinovou rychlostí proti IPv4. Takový problém uživatel popisuje tak, že „se mu videa z Youtube načítají hrozně pomalu“. Jen málokdo z toho okamžitě odhalí spojitost.
-
j (neregistrovaný)
Hlavne proto proste nebudou adresy, vlastne uz nejsou. 80% potizi se sitovanim ktere sem v poslednich minimalne 5ti letech resil byly dany tim, ze dotycny proste ... zadnou sit (internet) nemel. Nemel verejnou adresu = z jeho pohledu mu proste neco nefungovalo (trebas vymena souboru pres icq/jabber ..).
Dtto bezpecnost - NATujici firewall ma vetsinou 3-5tinasobek pravidel nez totez bez NATu. Coz zcela automaticky vede k chybam, prehlednutim ... daleko casteji. Uz vubec nemluve o takovych vecech jako ze se nejaky stroj z nejake interni natovane site snazi pripojovat na verejnou adresu toho natu ... (proste proto, ze googli DNS mu samo nerekne 192.168.2.3), coz jsou dalsi pravidla a dalsi chaos.
-
Santiago (neregistrovaný)
> Osobně věřím jen na dual stack, tyhle obezličky vyvolávají jen další problémy k řešení vyvolávají disproporce na síti a nemají smysl.
Dual stack je dobre reseni v okamziku, kdy ma ISP dost verejnych IPv4 adres, takze muze kazdemu uzivateli pridelit aspon jednu.
V okamziku, kdy IPv4 adresy dochazeji a ISP by stejne musel nasadit stavovy NAT, tak nasazeni MAP-E resi hned nekolik problemu najednou - zaprve umoznuje casem prejit na IPv6-only paterni sit, zadruhe odstranuje skoro vsechny komplikace s provider-based stavovym NATem (jak pro ISP tak pro uzivatele).
