Názory k článku Na návštěvě v IPv6 laboratoři: jste kompatibilní?
-
Martin Fridrich (neregistrovaný)
RFC 5006 bylo categorie Experimental a nahrazeno RFC 6106 v listopadu 2010 jenž je categorie Standart Track. Tudíž je pochcopitelné, že implementace do komerčních systémů (jedno jestli Unix type ne Win type) bude otázkou času a plánů releasů.A nokonec pro všechny systémy existuje banda fandů, kteří implementují různé věci i dříve než se stanou standardem.
http://sourceforge.net/projects/rdnssd-win32/
rdnssd-win32 is a userspace implementation of the RFC 5006 for Microsoft Windows. It updates the Windows registry with the IPv6 name servers found in the RDNSS option of the Router Advertisement. Thus no need to configure an IPv6 nameservers manually.
-
Martin Fridrich (neregistrovaný)
Nejsem si jist, jestli se MS oficiálně takto k plánům vyjadřuje. Zatím jen vím, že jeden ze zaměstanců se vyjádřil ve smyslu, že prozatím není v plánu. Spíše by za studium stálo kdy MS zařazuje do implementacu různé RFC tedy co je jejich kritériem pro akceptaci pro implementaci současné RFC k RDNSS je ve stavu proposed standard (cca 15 měsíců), předchozí bylo experimental (33 měsíců). dle wiki např. ani AIX a jiné uix nepodporují zatím RDNSS. Proto by bylo zajímavé i když ne Vaším úkolem, zjistit jakou mají jednotlivé společnosti základní politiku pro adopci standardů. (určitě nějaká bude). Výsledkem čehož by bylo zřejmé či odhadnutelné masové nasazení různých technologií či standardů.
-
MarSarK (neregistrovaný)
Hezká srovnávací tabulka je na WiKi
http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems
Zatím se mi nepodařilo dopátrat zda podporu pro RFC6106 má Dibbler. Na Windows se chová jinak dobře. Jinak podobné testovací prostředí na IPv6 máme na ČVUT, FEL na Karlově náměstí. Už jsme tu testovali kdejakou "krabičku". Poslední novinkou je třeba IPv6 schopná gateway od Eatonu na ovládání domovního bezdrátového systému xComfort. Postupně se podpora IPv6 zlepšuje, ale mohlo byt to jít svižněji.
-
Taková síť je na testy výborná. Zajímalo by mě, kdy jste byli na návštěvě, protože Novinky (resp. Seznam) mají IPv6 glue záznamy v DNS od úterý a Root (resp iinfo) měl do včerejšího dopoledne v glue nesprávné adresy, takže pokud DNS server na takové síti nemá IPv4 konektivitu, ani jedna ze služeb nemohla fungovat...
Zkouší tato laboratoř i funkčnost delegace prefixů?
-
Dobrý den,
nastavení DNS serveru ještě překontroluji, je možné, že tam zůstal zapomenutý forwarding na server s IPv4 konektivitou místo přímého dotazování, každopádně děkuji za upozornění.
Delegaci prefixů zatím netestujeme, ale máme jí v plánu, společne s rozšířením sítě o SOHO router, který umí pracovat s delegovanými prefixy, abychom mohli rovnou ukázat praktiké použití
Petr Černohouz
Laboratoře CZ.NIC -
vasek (neregistrovaný)
Nevíte někdo, jestli už se dá rozumně řešit bezpečnosti IPv6 na místních sítích? Např. pro nyní již neexistující firmu 3com a její chytré switche jde nakonfigurovat dhcp spoofing apod. nastavení zabraňující mít někde libovolný dhcp server, nastavení vyžadující, aby ip adresu přiděloval dhcp server a tudíš nemohlo dojít ke kolizi ip adres, arp spoofing ochrana apod. Jaké jsou současné technologie pro zabezpečení IPv6, kde arp bylo nahrazeno, dhcp plní jen podpůrnou funkcni ...?
-
Ondřej CaletkaZlatý podporovatelZ hlediska kompatibility DNS64 a DNSSEC se to má tak, že buď:
a) bude DNS64 provádět přímo validující resolver na koncové stanici až po validaci (otázka je však, jak získá místní prefix pro mapování IPv4 adres).
nebo
b) bude DNS64 provádět místní DNS server až po validaci a k němu budou koncové stanice připojeny zabezpečeným kanálem. Koncová aplikace se tak spolehne na důvěryhodnost místního DNS serveru a bude pracovat pouze s AD flagem. -
trex (neregistrovaný)
a) je rekl bych ve velkych sitich nepouzitelne, kdyz je snahou nasadit to plosne pro celou sit heterogennich klientu,
b) nejaky navod jak toho docilit resp. nejake delsi povidani, jak by ta konfigurace mela vypadat, aby se DNS64 provadelo az po validaci (predpokladejme, ze LAN je zabezpecena)? Diky -
Radek Hladik (neregistrovaný)
Naopak jste to pochopil naprosto přesně. DNSSEC a DNS64 jsou z principu nekompatibilní technologie - DNSSEC se snaží zabránit změně DNS záznamů na cestě mezi serverem a klientem , DNS64 pracuje na principu takovéto změny. Protože se v případě DNS64 jedná o "dočasný" mechanismus, tak se to moc neřeší a jsou možné ony dvě zmíněné varianty. Buď udělat na klientovi nejprve DNSSEC a pak DNS64, nebo "přesunout" DNSSEC klienta na DNS64 router a spoléhat se na to, že spojení mezi DNS64 routerem a opravdovým klientem je zabezpečeno jinak (=většinou nijak).
Laicky řečeno, nemůžete chtít vyplnit bianco šek v zapečetěné obálce bez toho, aniž by se pečeť rozbila :-) -
Radek Hladik (neregistrovaný)
Tato varianta vyžaduje dát si pozor na tři věci.
1) vůbec nebrání útoku z vnitřní sítě, což ve chvíli, kdy jsou všechny stroje dosažitelné z vnější sítě může být docela problém - tzn. je potřeba mít opravdu dobře nastavený firewall a všechny povolené vnitřní služby musí být dobře zabezpečené...
2) je potřeba hlídat, aby nepřišla nějaká DNS odpověď mimo resolver s AD flagem nastaveným
3) Administrativně je potřeba dát si pozor na to, že uživatel může získat "pocit bezpečí" , který není adekvátní úrovni zabezpečení. Tedy uživatel si není vědom 1) a 2) a přesto mu tam svítí zelené něco, co mu říka: "Vše je ok, je to zabezpečené" -
Radek Hladik (neregistrovaný)
Zdravím,
přiznám se, že by mně docela zajímalo, zda je v laboratoří možné vidět/vyzkoušet věc, kterou jsem už několikrát pod podobnými články řešil (naposledy tuším s Pavlixem na abclinuxu).
V principu mi jde o to, jak elegatně řešit, když chci mít síť připojenou více konektivitami (netřeba současně). Řekněme, že mám firmičku s 5ti počítači, miniserverem a ADSL. ADSL občas vypadává, tak si pořídí nějakého O2, ufona nebo nějakou místní nadšeneckou WiFi. U IPv4 je díky NATu na routeru změna konektivity otázkou přehození jedné default routy - mikrotik router v řádu 1000Kč to dokonce ve většině případů zvládne sám podle pingu gatewaye. U IPv6 se zatím jako nejpodobnější jeví varianta s něčím jako NAT 1:1, dále je možnost mít na všech počítačích dvojí adresy a snažit se, ať se volba dělá už tam, případně nějaké dynamické přeadresování všech počítačů.
První varianta je zatím, pokud vím, spíše ve stádiu experimentů a už má hodně odpůrců, protože se moc podobá IPv4 NATu (který pořád hodně lidí považuje za čisté zlo "by default" :-) ), druhé dvě varitanty vyžadují docela rozsáhlé operace při změně připojení.
Rád bych proto viděl nějaké funkční řešení, protože si myslím, že to je věc, která bude pro rozvoj IPv6 vcelku podstatná, protože co si budeme povídat, síť musí být už pořádně velká, aby (finančně i administrativně) dosáhla na variantu, kdy se učástní BGP routingu a pod. -
petr_p (neregistrovaný)
Elegance překladu adres na hraničním routeru je celá postavena na tom, že ji děláte na jednom místě, a výměnou obětujete příchozí spojení.
Můžete stejný postup použít i v IPv6, ale dostanete stejné problémy.
Násobné prefixy znamenají násobnou konfiguraci na všech prvcích sítě. Něco se dá centralizovat přes RA a DHCP, zbytek není ani standardizován ani komerčně dotažen na úroveň spotřebního zboží. To se ale nemůžeme divit, když ani hloupá podpora IPv6 není samozřejmostí u spotřebního zboží.
Jak správně píšete, drobná síť na BGP nedosáhne. Popravdě se správci páteřních sítí děsí představy, že by BGP tabulky nabobtnaly kvůli firmičkám s 5 počítači.
Vyřešit si to může sama firmička tak, že vytvoří poptávku po VPN nebo mobilitě.
Nebo počká až moudří akademici odděli roli identifikace a lokalizace IPv6 adresy do dvou nezávislých mechanismů (A Review of IPv6 Multihoming Solutions).
Osobně si myslím, že pro firmičku s 5 počítači je prozatím nejjednodušší dvojí adresování, neb má jen jeden router a stanice firewall v ŧovárním nastavení.
-
Radek Hladik (neregistrovaný)
Ano, klidně obětuju příchozí spojení, resp. klidně použiju nějakou formu mapování (u IPv4 DNAT). Podívejte se, kolik podobných firmiček používá "domácí" ADSL a víceméně jim vyhovuje. Vše, co potřebují je email, web, skype a pár podobností. A pokud jim ADSL začne padat, tak si prostě přikoupí něco druhého, klidně mobilního, ať se alespoň dostanou na emaily a web. Ekonomika je naprosto jasná a já nemám moc důvod je přesvědčovat, ať si pořídí násobně dražší "firemní" připojení.
Právěže stejnou věc u IPv6 použít nemůžu. Protože nemám k dispozici ten NAT, který byl základním stavebním kamenem toho řešení. Nejbližší varianta je to, kdy mám lokální site-specific adresy a dělám ten překlad 1:1. A to ještě potřebuju, aby mi všichni operátoři dávali stejný rozsah a ideálně alespoň /64.
Co se týče podpory IPv6 u spotřebního zboží, plně souhlasím s tím, že ta je mizerná. Ale v tom je význam nás odborníků, kteří jsou schopni nabídnout alternativu, kde to je jinak. Mikrotik v ceně 700-1000Kč má velmi dobrou podporu IPv6 a nevím o žádném důvodu, proč ho nedoporučit.
Plně si dovedu představit, jak by vypadalo BGP, kdyby se v něm objevovaly prefixy pro každou takovouhle firmičku. To jsem psal právě proto, že je nesmysl od takovýchto firmiček očekávat řešení, které je "oficiálně to správné". Ale upřímně řečeno firma se 100 počítači na tom nebude o moc lépe. U IPv4 se nepropagovaly rozsahy menší než /20, pokud si dobře pamatuju. Taková firma bude jen mít větší požadavky na šířku pásma a větší možnosti ze strany správců, ale principielně na tom bude stejně.
VPN, pokud se nepletu, celý problém jen posune. Tedy někdo mi přidělí nějaký rozsah, který mně pak nějak dopraví a ten transport bude nezávislý na použitém připojení. Takhle mám teď IPv6 doma - jeden rozsah z firemní sítě přes IPv4 tunel protlačený na hraniční router. Ale problém je pořád tu, pokud bych si pořídil záložní tunel přímo ode mně, tak jsem stejně nahranej. Tohle řešení sice odstraní závislost na konkrétním připojení, ale naopak zavede novou závislost na poskytovateli VPN :-) Přiznám se, že mobilitu jsem moc nestudoval, ale pokud se nepletu, tak to funguje tak, že příchozí spojení jde nejdřív na nějakého home agenta a ten pak řekne, kde se ve skutečnosti druhá strana nachází. Nevím, jak by to vyřešilo odchozí spojení a nedovedu si to moc představit u běžných poskytovatelů.
Ale právě proto jsem psal dotaz, zda je v laboratoři možné nějaké takovéhle řešení v praxi vidět, protože mně to docela zajímá. V principu mi jde o to, že až se mně zákazníci začnou ptát, tak jim nemůžu moc říct, že "ten nový internet" neumí to, co uměl "ten současný" :-) Stejně tak bych jim nerad dělal nějaké megakomplikované řešení, které nebude spolehlivé nebo bude náročné na údržbu. -
Radek Hladik (neregistrovaný)
Dva prefixy se dají použít dvěma způsoby. Buď mají všechny počítače pořád dva rozsahy a sami si volí správný při vytváření spojení ven. To znamená, že musí mít nějakou možnost, jak zjistit, který kdy použít. Navíc se problém z routeru "rozplyzl" do celé sítě. Nebo mají počítače jen právě ten aktuální rozsah, pak to znamená, že je potřeba nějaký mechansimus (RA, DHCP), který umí rozumně rychle všechny počítače "přeadresovat". To je proces, který není úplně triviální ani bezproblémový.
Dále je problém se spojeními v rámci vnitřní sítě (typicky spojení na nějaký ten serveřík), kvůli kterému musí mít počítače ještě site-specific adresu.
Myslím, že každý uzná, že všechny zmíněné varianty jsou značně složitější, než dnes u IPv4 běžné řešení s privátními adresy a poměrně tupým routerem/NATem. A ač současné řešení trpí spoustou neduhů, tak není realné chtít po všech zákaznících, aby přešli na něco složitějšího, pokud jim ty současné neduhy nevadí. -
Radek Hladik (neregistrovaný)
Osobně nemám rád to "tak nejak od prirody". U takovýhle zásadních věcí chci vědět přesně proč a jak to funguje. A děsím se toho, že si každý počítač bude sám volit cestu. Už jen ten algoritmus na volbu zdrojové adresy, který defaultně upřednostňuje IPv4 před některými tunel,y a člověk potřebuje diagram, aby věděl, jak se to zachová, mě odrazuje.
Linkové adresy jsou na vnitřní komunikaci málo, je potřeba něco nezávislého na síťovce a spol. Nemluvě o tom, že adresa, která se pěkně pamatuje taky není k zahozeni (ikdyž to už je jen bonus).
Ale přesně na tohle směřroval můj dotaz, jestli je možné takovou věc v NIC laboratořích vidět a vyzkoušet si, protože si dovedu představit, že to nějak fungovat bude a bylo by dobré s tím získat co nejvíce zkušeností. -
Propagaci dvou různých prefixů s různou (nebo i stejnou) preferencí směrovače není problém v laboratoři vyzkoušet. Upřednostnování IPv4 adresy před tunely je dáno logikou: "nativní konektivita je lepší než tunel" a v tomto ohledu mi to příjde naopak jasné a transparentní
Petr Černohouz
Laboratoře CZ.NIC -
Sten (neregistrovaný)
Algoritmus na volbu zdrojové adresy je dán precedenční tabulkou (v Linuxu je uložena v /etc/gai.conf), přičemž RFC definuje jen její výchozí stav (zjednodušeně řečeno: preferuj levnější/kratší spojení a IPv6).
Linkové adresy (fe80::/64) si klidně můžete nadefinovat vlastní, nezávislé na síťovce a snadno pamatovatelné, RFC to umožňuje.
-
Radek Hladik (neregistrovaný)
To RFC jsem četl. Velice zajímavé čtení a plně chápu jeho důvody, atd... Stejně jako chápu, proč je lepší upřednostňovat IPv4 před tunelem. Ale i přesto si stojím za tím, že algoritmus o asi 8mi korcích, konfigurační tabulkou a dalšími případnými zadrhelovými místy bych radši viděl na routeru (=jednom centralizovaném místě) než na každé divoké stanici. Je to sice trochu přehánění, ale nechci moc řešit situace typu "vaše tiskárna nerespektovala prioritu prefixu a proto nejede", "ten nový cosiMac je skvělý, ale nějak mu trvá, než zjistí, že připojení nejede", "ten prográmek na optimalizaci spojení vám krásně nastavil tabulku preferenci, jen jí trochu rozvrtal :-)"
-
Radek Hladik (neregistrovaný)
Podívejte se, jak to router dělá u dnes velice rozšířeného schématu s IPv4+NAT. Volba zdrojové adresy je přesunuta na router, protože stanice vždy použije jednu fixně přiřazenou a router tu adresu změní podle potřeby. Ve skutečnosti je to přesně to, co zpochybňujete ve vašem příspěvku, že by nějak vůbec mohlo jít.
To, že zmíněné řešení s NATem má jiné nevýhody, dobře vím. Stejně tak řešení s distibucí více prefixů má (mimo jiné) tuto nevýhodu, že přesouvá netriviální část logiky na jednotlivé klienty.
Ve skutečnosti je to hodně debata o tom, zda přizpůsobovat technologii potřebám nebo potřeby technologii. Ale stojím si za tím, že zatím všechna takováto řešení jsou v případě nastíněného problému malé sítě ve finále komplikovanější, složitější na údržbu a náročnější na chybu. A k tomu, abych přesvědčil zákazníky, aby přešli na něco nového, co jim zkomplikuje život, bych potřeboval opravdu schopné marketingové oddělení :-) -
Sten (neregistrovaný)
NAT je obezlička, která pořádně nefunguje. Kromě toho, že klient se nedozví, kdy a jak se změnila jeho vnější IP adresa (což je potřeba vědět třeba při streamování), tak jak router změní adresu v šifrovaném FTP či jak namapuje porty v šifrovaném SIPu? To totiž ta volba zdrojové adresy dělá taky.
Komplikovanější to je, jen pokud to chcete použít jinak, než bylo otestováno, že to funguje velmi dobře. IPv6 má naopak (díky autokonfiguraci a prefix delegation) nutnou údržbu minimální a zprovoznění je podobné zprovoznění IPv4 + DHCP (a NAT nastavovat nemusíte).
-
Radek Hladik (neregistrovaný)
"NAT je obezlička, která pořádně nefunguje."
Tohle je nepravdivé tvrzení.Dostáváme do jiné oblasti, než původně, takže se předem omlouvám za off-topic.
Jsme technicky založení lidé, takže bychom měli názory trochu precizovat a nepoužívat podobné vágní a nepřesné tvrzeni. NAT je technologie, která má určité + a určité -. V rámci těchto + a - funguje pořádně a správně. Obezlička není technický termín, to není potřeba komentovat (to bych pak klidně mohl tvrdit IPv6 je obezlička a pořádně nefunguje (např. protože se nepřipojí na IPv4 hosty)). Dokonce si troufnu souhlasit, že z "principelního" hlediska je těch - víc než těch +.
Na druhou stranu máme hodně zákazníků, kteří mají pár počítačů, šiforvaný SIP/FTP nepoužívají, zato "rádi" připojují různé divoké zařízení (mobily, různé tablety, tiskárny a já nevím co všecko). Oni běžně používají maximálně web+mail+skype/icq. Tedy naprostou většinu mínusů současného řešení prostě neřeší, protože je nepoužívají. A ano, dá se i říci, že je nepoužívají právě kvuli těmto mínusům. Ale principelně, pokud jim budu nabízet něco nového/lepšího, tak to nesmí v tak poměrně zásadní věci horší. A právě proto můj prvotní dotaz směřeoval přesně na to, zda je možné takovéto řešení v laboratoři vidět (na což jsem už dostal odpověď výše), protože takovýchto principielních/teoretických diskuzí už jsem několik absolvoval, ale každé zmiňované řešení mělo zase nějaké + a nějaké -.
Samozřejmě, pokud se budeme bavit o jiném typu zákazníků (třeba firma s 20-50 počítači), kde je možno si dovolit více nákladů na správu a jsou větši požadavky na konektivitu, tak to bude něco jiného. Proto jsem svůj prvotní dotaz vymezil.
A co se týče složitosti nastavení NATu, to bych jako problém neviděl, jedno masquerade pravidlo na jednom místě v jendom firewallu není žádný problém. -
Radek Hladik (neregistrovaný)
Většinou mi komentáře takovéto úrovně nestojí ani za odpověď, ale budiž :-)
To je fakt mánie těch ANTINATářů. Občas mám pocit, že svolám na nějaký jejich náboženský svátek (asi na Sv. FTPa) nějaké srocení a pak tam budu skandovat proNATovská hesla :-) Ale pak si vždycky řeknu, že bych mohl rozpoutat svatou válku, protože se jedná o lidi, kterým se při zaslechnutí "NAT" zatmí před očima a ztratí veškerou soudnost.
Po odborné stránce nemám co dodat, snad kromě toho, že vás možná překvapí, že jsou lidi, kteří nepoužívají FTP (ani šifrované)...
-
Radek Hladik (neregistrovaný)
Musím řict, že na odpůrce NATu jste projevil až nadprůměrnou míru chápavosti. Ano, pokud mám technologii, která něco umožňuje, tak používám, to, co umožňuje. A pokud potřebuju používat něco, co neumožňuje, tak to buď nepoužívám nebo změním tu technologii, která mi v tom brání. Už vám ovšem uniklo, co jsem psal, že jsou lidé, kteří některé věci nepoužívají, protože je nepotřebují, nikoliv proto, že je nemohou používat.
-
Sten (neregistrovaný)
Pokud vám nevyhovuje český termín obezlička, stačí místo něj použít anglický termín workaround, který se v technické literatuře používá běžně. Nic jiného totiž SNAT není (DNAT je trochu jiná kategorie a s maškarádou nemá nic společného).
Jaké tam jsou plusy? Snad jediný — stačí vám jedna IP adresa.
Běžně používají ten Skype, protože nic jiného přes NAT neprojde. Co na tom, že všechny chytré telefony už tak tři roky umí SIP, když si s ním stejně nezavoláte.
Pokud vám stačí jedna maškaráda, stačí vám v IPv6 ta výchozí tabulka, takže IPv6 je na tom zase líp (funguje to bez nastavování). Když jste se na tu tabulku totiž ptal, čekal jsem, že používáte něco komplexnějšího, kde je třeba více připojovacích cest. To byste teprve věděl, jak „úžasný“ ten NAT umí být.
-
Radek Hladik (neregistrovaný)
Celou dobu řeším přesně tu situaci, kterou jsem nastínil v prvním příspěvku. A vím, jak složitý a problematický dokáže NAT být. A věřte mi, že na několik příchozích spojení bych ho nepoužíval. Osobně totiž jeho výhody i nevýhody velmi dobře znám a právě proto nejsem ani zarytý odpůrce ani zarytý příznivce, ale prostě vím, kdy se ta technologie hodí, kdy ne, co přinese a co způsobí. V kontextu této diskuze jsem to uvedl jako protipřiklad ilustrující, že i volbu zdrojové adresy je možné přesunout na router (samozřejmě za určitých podmínek).
A přiznám se, že na použití slova obezlička ve smyslu workaround nejsem zvyklý, v tom případě beru zpět to, že to není technický termín. -
Filip JirsákStříbrný podporovatelZákladním stavebním kamenem tohoto řešení není NAT, ale routování. Nějakým způsobem vyberete odchozí cestu a podle toho pak odchozí IP adresu. NAT v tom nijak nefiguruje.
-
Karel (neregistrovaný)
Není to spíš o výhodách spojených s tím, že počítač nemusí řešit, že se mu adresa změní? Internet není neměnná stromová struktura, ale je to velmi proměnlivý graf plný smyček. Je zajímavé, že protokoly pro routování tohle už dávno obstojně vyřešily, zatímco IPv6 to pro koncové body "rozbila". Mám pevnou IPv4 adresu a můžu přepnout na záložní linku bez toho, aby se mi vůbec přerušilo TCP spojení. Asi jste se setkali s tím, že se vám "někde na lince" něco stalo a vaše pakety šly chvíli jinudy. O tom ten protokol je. Jediné, co musíte udělat, je na vašem počítači nastavit pevnou IP adresu. No a NAT je jeden ze způsobů, jak si ulehčit práci - nastavíte si pevnou IP adresu na routeru a dohodnete se na ní se všemi svými providery. Za NATem můžete mít počítače s dynamickou adresou, které nijak neovlivní, že váš router najednou nejede přes providera A, ale přepnul na providera B. S IPv6 to zatím vypadá, že ta pevná IP adresa se bude muset nastavit na každé zařízení a při komunikaci s poskytovateli budou potřebovat váš seznam adres. Což se nám zatím nepodařilo, všichni tři naši poskytovatelé trvají na tom, že počítače připojené přes ně musí mít jimi přidělený prefix. Jenže to TCP spojení nemá šanci přežít, protože jakkoliv je dobré na hledání alternativní cesty, změnu IP adresy koncového zařízení nevydýchá.
-
Sten (neregistrovaný)
To bych teda chtěl vidět. Jak se druhá strana, která používá vaši veřejnou IPv4 adresu, tedy tu, kterou vám přidělí NAT, o tom přepnutí dozví, když budete používat NAT jiného poskytovatele? Pokud tedy nemáte dva providery používající stejnou veřejnou IP adresu.
Na druhou stranu IPv6 umí automatické přepnutí na základě Router Advertismentu (ve výchozím stavu bude aktivní spojení přes oba providery a při problémech se prostě ohlásí, že se jeden odpojil) a díky IPv6 Mobile se ta druhá strana tu změnu IP adresy dozví (pokud to tedy ten provider, co mu spadne síť, má správně nastavené), takže tam se TCP spojení opravdu nepřeruší.
-
Zajimalo by me, jak nasazeni IPv6 resi provideri v souvislosti s data retention.
Podle data retention bych mel byt vzdy schopen priradit IP adresu ke konkretnimu uzivateli, abych mohl pripadny nelegalni provoz napraskat flojdum.
To pro me znamena bud staticka konfigurace IP adresy (neprakticke) nebo vyuziti DHCPv6 se staticky definovanymy leases. Problem je v identifikatoru uzivatele. U ipv4 to byla MAC adresa sitovky, ktera se prilis casto nemenila a i kdyz se zmenila (uzivatel si zmenil sitovku nebo si pripojil jiny pocitac) tak se dala vazba 'neznama MAC - uzivatel' dohledat (napriklad pomoci option 82 priznaku v DHCP pozadavku, ktery obsahuje identifikaci portu switche/modemu, ze ktereho DHCP pozadavek prisel)
Jak toto resit v IPv6 svete? V DHCPv6 uz neni identifikator pozadavku MAC adresa ale nahodne vygenerovany retezec, ktery se muze necekane menit. Jak tedy zajistit, abych vzdy vedel, ke kteremu zakaznikovi patri konkretni IP adresa?
-
To by slo.
Je tu sice drobna nevyhoda oproti staticke rezervaci IP adresy (nebo /64bit prefixu), protoze dopredu nevim, jakou IP/rozsah uzivatel dostane. Tim padem nemuzu nastavit ip filtry na uzivatelove pripojnem bode, aby mohl komunikovat pouze s adresou, kterou mu pridelim. Tim padem hrozi nebezpeci, ze zaskodnicky uzivatel 'ukradne' ip adresu jineho zakaznika a zpusobi tim IP konflikt na siti. Diky velmi sirokemu adresnimu prostoru IPv6 je vsa pomerne obtizne trefit se do IP adresy, kterou pouziva nekdo jiny takze to asi nebude zas takovy problem.
-
Pekny clanek o bezpecnostnich problemech spojenych s nasazenim IPv6 napr. zde: http://blog.ioshints.info/2011/10/ipv6-end-user-authentication-on-metro.html
-
Sten (neregistrovaný)
U nás už data retention není povinný.
Řešení je celkem jednoduché a IMO je mnohem jednodušší, než pro IPv4: každý klient dostane celou síť (/64, na požádání až /48) a na switchi se provede filtrování portů podle sítě. V té síti si potom uživatel může přidělovat adresy, jak je libo, protože se jeho počítače poznají podle prefixu.
-
Add data retention: je to zruseno jen docasne, ustavni soud nezamitl data retention jako celek, pouze se mu nelibila nektera specifika ceske implementace teto smernice EU. Takze ocekavam ze v pozmenene podobe zacne data retention brzo opet platit.
Add problem s identifikaci klienta: jak chcete provest prideleni celeho rozsahu /64 nebo /48 konkretnimu klientovi? Bud byste musel pouzit DHCPv6 a opet nam tu vyvstava potiz s promenlivymi DUID (tak se nazyva identifikator klienta v DHCPv6) a nebo by jste musel rozdelit sit na druhe urovni ISO/OSI a kazdemu klientovi priradit jeho vlastni VLAN - toto reseni nejspis je mozne a i se mi celkem pozdava ale bude to teda velka zmena oproti soucasnemu stavu, kdy u nas jeden sitovy segment sdili stovky klientu a bezpecnost je zajistena pomoci IP source guard (ip filtru) na pristupovych bodech do site.
-
Sten (neregistrovaný)
Přidělování adres ze sítě /64 se většinou řeší pomocí prefix delegation podle VLANy (které jsou mapované na jednotlivé porty switche), přičemž router podle těch VLANů rovnou routuje (spolu s reverse path filterem). Modemy s podporou IPv6 většinou prefix delegation umí, takže po nastavení switche je stačí u klienta jenom zapojit (a klient klidně může použít nějaký vlastní, pokud k tomu má důvod). Jestli pak doma použije klient DHCPv6 nebo autokonfiguraci, může být čistě na něm. Jediný problém by tak mohlo být to, že nevím o žádném automatizovaném systému, co by ty VLANy spravoval.
IP Source Guard je hodně nespolehlivý, protože spoléhá na to, že klient nefalšuje MAC adresu jinou ze stejného segmentu sítě.
-
Sten (neregistrovaný)
Privacy extension je něco jiného, to slouží, aby firmy nebo tajné služby nemohly sledovat, kudy se nějaký uživatel pohybuje (bez privacy extension jednou zjistíte, komu patří konkrétních spodních 64 bitů, a můžete jej sledovat prakticky po celém světě), případně kolik má daná síť stanic (i když jsem nepochopil, k čemu je tohle dobré), ale policie (u nás s příkazem soudu) může toho uživatele pořád dohledat přes ISP podle adresy jeho sítě.
-
Smíšek (neregistrovaný)
Ahoj, máte někdo skušenosti s IPV6 tunelováním od tunnelbroker.net a serverem v Praze. No teď to testuju, ale oproti německým serverům je to bída v podporovaných sítích. Nevím pod jakou sítí běží root, abičko, nix, ale jsou věčně pomalé až nefunkční, vyjímaje novinky.cz ty musí mít dobrou ipv6 základnu. Jinak ping na české ipv6 podporované servery je jen o pár ms horší než ipv4, včetně roota, abíčka a ostatních.
