abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 06:00 | Zajímavý článek

USA Network vysílá již třetí sérii seriálu Mr. Robot (Wikipedie, ČSFD.cz). Ryan Kazanciyan, technický konzultant seriálu, se na Medium v sérii článků Mr. Robot Disassembled věnuje jednotlivým dílům a popisuje použité nástroje a postupy.

Ladislav Hagara | Komentářů: 2
včera 23:55 | IT novinky

Společnost StartCom oficiálně oznámila, že jako certifikační autorita končí. Od 1. ledna 2018 přestane vydávat nové certifikáty a následující 2 roky bude poskytovat OCSP a CRL. Počátkem roku 2020 budou všechny platné certifikáty zneplatněny.

Ladislav Hagara | Komentářů: 20
včera 22:00 | IT novinky

Hodnota Bitcoinu, decentralizované kryptoměny, překonala hranici 8 000 dolarů [reddit].

Ladislav Hagara | Komentářů: 3
včera 21:55 | Zajímavý software

Byla vydána verze 10.0 linuxové distribuce Raspberry Digital Signage. Jedná se o distribuci pro jednodeskové počítače Raspberry Pi určenou k prezentačním účelům (veletrhy, prodejny, ...). Po naběhnutí systému je spuštěn webový prohlížeč v režimu celé obrazovky a vybraná prezentace. Nejnovější Raspberry Digital Signage vychází z distribuce Raspbian Stretch.

Ladislav Hagara | Komentářů: 0
včera 13:33 | Zajímavý software

Společnost Google na svém blogu věnovaném open source představila container-diff, nástroj pro analýzu a porovnávání Docker kontejnerů. Zdrojové kódy jsou k dispozici pod licencí Apache 2.0.

Ladislav Hagara | Komentářů: 0
včera 08:00 | Komunita

Flatpak Workshop proběhne ve středu 29. listopadu od 10:00 v Brně. V dopolední přednáškové části se účastníci seznámí s Flatpakem, se specifiky pro aplikace napsané v Qt a GTK+, portály, které integrují aplikace do systému, a na závěr, jak dostat aplikaci do Flathubu, což je momentálně největší centralizovaný repozitář Flatpaků. V odpolední části si pak mohou za pomoci lektorů zkusit nějakou aplikaci zabalit pro Flatpak. Workshop je určen pro 20 účastníků. Nutná je registrace.

Ladislav Hagara | Komentářů: 6
včera 07:00 | Zajímavý článek

Software Freedom Law Center a Software Freedom Conservancy jsou organizace zaměřené na podporu svobodných/open-source projektů: SFLC poskytuje právní konzultace, SFC mj. také zázemí. SFC upozornila, že ze strany SFLC vůči ní proběhly právní kroky směřující k odebrání obchodní známky. SFLC v reakci tvrdí, že se jedná o logický krok, protože obchodní známky jsou si podobné, a SFC dlouhodobě nekooperuje. Brian Lunduke situaci shrnuje včetně ohlasů Neila McGoverna a Matthewa Garretta. Podle nich je Eben Moglen ze SFLC v konfliktu se zájmy komunity.

Fluttershy, yay! | Komentářů: 2
včera 06:00 | Komunita

MariaDB Foundation, nadace stojící za vývojem open source relační databáze MariaDB, oznámila, že Microsoft se stal jejím členem a platinovým sponzorem. Cílem Microsoftu je optimalizace MariaDB pro cloudovou platformu Microsoft Azure.

Ladislav Hagara | Komentářů: 0
16.11. 23:44 | IT novinky

Společnosti Dell a Canonical společně představily 5 nových počítačů Dell Precision s předinstalovaným Ubuntu. Jedná se o 4 notebooky a 1 all-in-one počítač. Cena počítačů s Ubuntu je o 100 dolarů nižší než jejich cena s Windows 10.

Ladislav Hagara | Komentářů: 15
16.11. 22:55 | Nová verze

Po pěti měsících vývoje od vydání verze 4.8 byla vydána nová verze 4.9 svobodného open source redakčního systému WordPress. Kódové označením Tipton bylo vybráno na počest amerického jazzového muzikanta a kapelníka Billyho Tiptona.

Ladislav Hagara | Komentářů: 0
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (9%)
 (1%)
 (1%)
 (1%)
 (74%)
 (14%)
Celkem 710 hlasů
 Komentářů: 36, poslední 17.11. 18:43
    Rozcestník

    Architektura IPv6 – konfigurace adres a objevování sousedů (2)

    22. 6. 2011 | Pavel Šimerda | Sítě | 11206×

    Jak jsem sliboval, podíváme se na různé možnosti přidělování adres protokolu IPv6. I podle místních diskuzí v této oblasti panuje značný zmatek a pro některé změny oproti IPv4 stále ještě představují spíše černou magii.

    Protokol IPv6, stejně jako IPv4, potřebuje posílat pakety s chybovými zprávami a režijními informacemi. Používá se k tomu protokol ICMPv6 (RFC 4443). Objevování sousedů a routerů (RFC 4861) a na něm založená automatická konfigurace adres (RFC 4862) jsou realizovány právě pomocí ICMPv6 paketů.

    Obsah

    Bezstavová konfigurace linkových adres

    link

    Ve světě IPv4 jsou linkové adresy (adresy z rozsahu 169.254.0.0/16, RFC 3927) spíše na okraji zájmu. Je to z toho důvodu, že IPv4LL adresy nejsou dostupné vždy, ale používají se pouze když stroj nemá přidělenou řádnou IPv4 adresu. Slouží tedy jen jako dočasná náhražka.

    Naproti tomu linkové IPv6 adresy jsou nedílnou součástí protokolu IPv6 a jsou specifikovány přímo v RFC 2460. Stroje si je přidělují samy při aktivaci síťového rozhraní, a ponechávají si je až do jeho deaktivace. Vznikají složením prefixu fe80::/64 a 64bitového identifikátoru síťového rozhraní, stroj si tedy linkovou adresu přiděluje zcela samostatně. O výběru identifikátoru síťového rozhraní a řešení duplicit bude řeč později.

    Linkové adresy se dají používat i pro běžnou komunikaci po místní síti, jen je potřeba, aby aplikace vždy kromě IP adresy znala i síťové rozhraní (všechny používají stejný prefix). V ideálním případě si aplikace obě informace zjistí bez ručního zadávání.

    K čemu tedy takové adresy slouží? Jednak je můžete použít k přímé komunikaci mezi dvěma zařízeními, které propojíte například ethernetovým kabelem. V mnohých případech bude jedno z těch zařízení běžný počítač a druhé bude jednoúčelové zařízení (například tiskárna). Nebo ad-hoc wifi sítě jsou na linkové adresy jako dělané. Síťaři využijí link-local adresy ke konfiguraci síťového prvku, který není zkonfigurován pro lokální síť a byl by jinak na IP vrstvě nedostupný. A jistě najdete další. Na linkových adresách funguje mnoho infrastrukturních protokolů jako NDP, DHCP, ale třeba i OSPF.

    Objevování linkových adres sousedů

    link

    Ke komunikaci po LL adresách je potřeba, aby komunikující počítače znaly MAC adresy odpovídajících síťových rozhraní. K tomu se používají pakety neighbor solicitation (NS) a neighbor advertisement (NA). Jedná se o variaci na klasický model dotazu a odpovědi, s možností rozesílat oznámení (NA) při změnách. Oba typy zpráv jdou posílat pomocí unicastu konkrétnímu stoji i rozesílat pomocí linkového multicastu všem (obdoba IPv4 broadcastu).

    Objevování sousedů pomocí protokolu NDP je víceméně přímou náhradou protokolu ARP z IPv4. A stejně jako ARP, se NS+NA hodí pouze k překladu L3 (tedy IPv6) adresy na L2 adresu. NDP v jeho základní podobě nenabízí žádné zabezpečení proti lokálním útokům, stejně jako IPv4 ARP. O možnosti jak toto změnit se dočtete v sekci o CGA a SEND.

    Chcete-li objevování sousedů obohatit o jména počítačů a dostupné služby, je potřeba použít další protokol. V prostředí Linuxu (ale také Applu a mnoha dalších zařízení) se nejčastěji používá Multicast DNS (mDNS), implementovaný například sadou nástrojů Avahi.

    Objevování routerů

    link

    Obdobným způsobem se získávají informace o routerech. K tomu se používá dvojice paketů router solicitation (RS) a router advertisement (RA). U routerů se počítá s tím, že jednou za čas informace o sobě do sítě rozešlou samy pomocí nevyžádaného oznámení. Oznámení se zpravidla posílá pomocí linkového multicastu, ale můžou se posílat i unicastem, například kvůli testování.

    Objevování routerů je také základem pro všechny metody automatické konfigurace adres. Na to je potřeba myslet kdykoli chcete nasazovat IPv6 na jakékoli síti. V závislosti na tom, co obsahují oznámení routerů se koncový stroj teprve dozví, jakým způsobem bude získávat svoji globální IP adresu. Součástí oznámení routeru jsou také informace o lokálních prefixech, routách do jiných sítí a DNS (RFC 6106). Není žádný problém mít na síti více než jeden router (například kvůli redundanci).

    Běžné objevování routerů trpí problémem falešných routerů. Do jisté míry tomu pomáhají programy jako ramond nebo rafixd, ale nemůžou zachytit vše. Finálním řešením je buď RA Guard na síťových prvcích (RFC 6105), SEND na routerech a koncových strojích (RFC 3971) nebo jejich kombinace.

    Bezstavová automatická konfigurace globálních adres

    link

    Bezstavová autokonfigurace (SLAAC, RFC 4862) je specifická metoda pro IPv6. V IPv4 sice něco podobného existuje, ale použitelnost je opět velmi omezená. Koncové stroje při připojení do IPv6 sítě kontaktují router pomocí RS. Router odpoví oznámením síťových prefixů s příznakem, že si koncový stroj smí sám nastavit IP adresu doplněním identifikátoru rozhraní. K automatické konfiguraci je potřeba jeden nebo více routerů a jeden nebo více síťových prefixů s příznakem samostatné konfigurace (AdvAutonomousFlag).

    Pokud některý router pošle informace o síťovém prefixu s tímto příznakem, koncový stroj si sám zvolí 64bitový identifikátor pro dané rozhraní (interface identifier). Síťový prefix dohromady s identifikátorem dávají celou adresu. Je tedy potřeba, aby i síťový prefix byl 64bitový. Příznak AdvOnLink určuje, zda koncový stroj může stroje ze stejné podsítě kontaktovat přímo pomocí objevování sousedů.

    V SLAAC se počítá s tím, že se každému stroji, který má komunikovat s vnějším světem, oznámí alespoň jeden globální prefix. Oznamovaný prefix je opatřen i dobou platnosti a dobou upřednostňování před jinými prefixy, která přechází na automaticky konfigurované adresy. Zkrácením těchto hodnot lze zajistit, že koncové stroje budou neustále sledovat, jestli router i nadále oznamuje jejich prefix a v případě změny prefixu se automaticky přizpůsobí a začnou používat adresy z nového prefixu. Při plánovaných odstávkách je můžete dokonce nechat přejít na nový prefix postupně, bez narušení služeb.

    Bezstavová automatická konfigurace unikátních lokálních adres

    link

    Stejným způsobem, jako se konfigurují globální adresy, se konfigurují i unikátní lokální adresy. Hodí se především pro prostředí bez připojení k Internetu, prostředí, kde je připojení k internetovým službám realizováno pouze přes aplikační proxy nebo prostředí, kde se můžou střídat globální prefixy. Na testování bez globální konektivity rovněž doporučuju používat ULA. V globálním DNS by se ULA neměly vyskytovat vůbec.

    ULA se na lokální úrovni ve všech ohledech chovají jako globální adresy, proto je ve zbytku článku nebudu ani uvádět jako samostatný případ.

    Identifikátory interface pro bezstavovou konfiguraci

    link

    Tvorbě identifikátorů rozhraní jsem se rozhodl vyčlenit samostatnou sekci, protože se týká linkových adres, globálních adres i unikátních lokálních adres. Připomínám, že ve všech případech bezstavové konfigurace si identifikátor rozhraní určují koncové stroje samy.

    Základní varianta (EUI-64)

    link

    Nejjednodušší a administrativně nejpříjemnější možností je nechat počítače, ať vždy používají stejný identifikátor uložený v hardware. Obvykle se používá 64bitová varianta identifikátoru EUI, který jde odvodit například z ethernetové (MAC) adresy ve formátu EUI-48 (doprostřed se doplní dvojice bajtů ff:fe). Identifikátor rozhraní se pak vyrobí z EUI-64 negováním patnáctého bitu (aby se ručně konfigurované adresy nepletly s těmi založenými na EUI). To vše je popsáno v RFC 2464.

    Adresy založené na EUI se používají jak pro linkové, tak i pro globální adresy. Její největší výhodou je, že se automaticky chovají jako statické adresy (alespoň při zachování prefixu a MAC adresy). Tím v mnohých případech odpadá potřeba ručně konfigurovat adresy či mapování mezi MAC a IP, které je zde automatické. Vyhnete se tím i použití dynamického DNS a podobným věcem.

    Duplicitní adresy se řeší metodou „moudřejší ustoupí“, což s sebou přináší svá rizika. Linkový segment lze zabezpečit filtrováním na switchi, ale jen částečně. Lze určit, na kterém portu smí sídlit router a vůči linkovým i globálním adresám vést politiku typu „kdo dřív přijde, ten dřív bere“. V mnoha sítích se ochrana proti útokům na tabulku sousedů neřeší ani v případě IPv4. Tyto sítě budou typickým místem pro nasazení takto jednoduchého způsobu konfigurace adres.

    Použití statických globálních adres pro odchozí spojení vás samozřejmě připraví o proměnnou složku, která má určitý význam z hlediska bezpečnosti a soukromí. To se projeví hlavně při pohybu mezi sítěmi. První polovina adresy obvykle určuje vaši polohu a druhá identitu. Při pravidelné komunikaci může kterákoli protistrana z vaší IP adresy vysledovat kudy se pohybujete. Nicméně podobnou „službu“ poskytují třeba cookies protokolu HTTP.

    Dočasné náhodné adresy (privacy extensions)

    link

    Problémy se soukromím a sběrem statistických dat z MAC adres řeší rozšíření nazývané privacy extensions (RFC 4941), které přidávají ke stávajícím adresám dočasnou náhodnou globální adresu.

    Protože náhodné adresy řeší pouze tento problém se soukromím, nemá smysl používat je pro linkové adresy. To by přineslo jen zbytečné komplikace. Snad jedině že při případné duplicitě se může zvolit nová náhodná adresa. Touto podle mého nešťastnou a zbytečnou cestou se jak se zdá vydaly nové verze Microsoft Windows. Dočasná adresa se používá pro všechna odchozí spojení a čas od času se změní (běžících spojení se změna netýká). Náhodná adresa už sama neumožňuje sledování pohybu, získání informací z MAC adresy. Dočasnost adresy výrazně ztěžuje odhady počtu zařízení v síti.

    Privacy extensions tak dávají daleko širší a hlavně spolehlivější možnosti skrývání vnitřních adres než NAT. Zbývá jen to, že protistrany, které znají dočasnou adresu, můžou zkoušet známé porty či skenovat porty. To se dá řešit velmi jednoduchým stavovým firewallem (po cestě nebo na stroji samotném). Nebezpečí samozřejmě zůstává v cestách, které koncový stroj aktivně otevírá.

    Při použití náhodných adres se ještě více projevuje zahození klasického předpokladu, že koncový stroj používá pouze jednu IP adresu. Není neobvyklé, když má notebook jednu link-local adresu, jednu automaticky konfigurovanou statickou adresu, náhodnou adresu pro dříve otevřená spojení a další náhodnou adresu pro nová spojení.

    Toto schéma už z principu nemůže poskytnout statické globální adresy. Pokud byste chtěli mít v rámci každé sítě statickou adresu a zároveň nebýt sledovatelní pomocí IPv6 adres, museli byste jako identifikátor interface používat hash sestavený ze síťového prefixu a nějakých neměnných údajů z vašeho počítače. Technicky velmi jednoduché, ale nikde jsem podobnou funkci neviděl.

    Na linuxových distribucích se dočasné adresy zapínají pomocí sysctl (hledejte use_tempaddr).

    Kryptografické adresy (SEND)

    link

    Protokol pro objevování sousedů a routerů je podobně zranitelný jako protokol DHCP používaný v IPv4. Tím, že je celá konfigurace jednodušší je i o něco jednodušší tyto zranitelnosti využívat. Kryptografická varianta tohoto protokolu se snaží tuto situaci zlepšit na úroveň, která s IPv4 nepřipadala v úvahu.

    Základním pilířem jsou kryptografické adresy (RFC 3972) chráněné soukromým klíčem a ověřitelné veřejným klíčem. Protokol SEND (RFC 3971) zavádí podepisování zpráv protokolu NDP, čímž brání jejich falšování a zabraňuje tak některým typům útoků. Koncová zařízení si můžou vzájemně kontrolovat NDP zprávy a řídit se jen těmi podepsanými. K ověření, jestli je stroj oprávněným routerem, se používají certifikáty a řetězec důvěry. Do koncových strojů stačí instalovat certifikát kotvy důvěry, router pak musí koncovému zařízení ke kontrole předložit celý řetězec. Nezabezpečené NDP a SEND spolu mohou koexistovat. Stroje pak dávají vždy přednost zabezpečené informaci před nezabezpečenou.

    Tento protokol je relativní novinka a na jeho implementaci zatím běžně nenarazíte. Existují ovšem experimentální projekty, které fungují na Linuxu a FreeBSD. I bez použití certifikátů lze na SENDu postavit velmi zajímavé řešení, pokud ho zkombinujete s filtrováním na switchi. Uvidíme, co se z toho vyvine.

    Stavová automatická konfigurace (DHCP)

    link

    Je vcelku pochopitelné, že bezstavová automatická konfigurace nevyhovuje všem a za všech okolností. Proto ohlášení routeru může bezstavovou konfiguraci nepovolit a místo ní povolit koncovým strojům konfiguraci stavovou čili řízenou (AdvManagedFlag). Narazíte ale na dva zásadní problémy, které vás donutí se blíže zabývat obsahem RA. Jednak nemůžete konfigurovat linkové adresy pomocí externího serveru, což znamená, že se nevyhnete problémům s lokálním zabezpečením. A druhak o oznámení výchozí brány se vždy starají routery samy.

    DHCPv6 (RFC 3315) tedy slouží k řízenému přidělování adres koncovým strojům (oproti situaci, kdy si adresy přidělují samy). Vychází z protokolu DHCP pro IPv4 (RFC 2131). Uzly se můžou účastnit stavové konfigurace ve třech různých rolích. Klient je koncové zařízení, které komunikuje pomocí linkové adresy a pokouší se získat konfigurační parametry od dhcp agenta nebo serveru na linkové multicastové adrese ff02::1:2. Agent je zařízení, které komunikuje pomocí linkové adresy s klientem a zprostředkovává mu komunikaci se serverem. Server dodává konfigurační parametry na základě žádosti klienta (ať už přes agenta, nebo přímo po linkové vrstvě).

    Přidělování dynamických adres z poolu

    link

    V celku bezúdržbové konfigurace se dá dosáhnout tak, že se DHCP server nastaví, aby přiděloval adresy dynamicky z nějakého menšího rozsahu. Klienti dostanou propůjčenou adresu, kterou si musí po nějaké době obnovovit. Server má navíc možnost požádat klienta o rekonfiguraci kdykoli. Server může spolupracovat s DNS serverem a s jeho pomocí zveřejňovat údaje o aktuálně připojených strojích.

    Dočasné náhodné adresy

    link

    Na požádání klienta může server generovat dočasné náhodné adresy. Oproti samostatně generovaným náhodným adresám je tu možnost automaticky předávat IP do nějaké databáze (například pro firewall nebo interní DNS).

    Statické přiřazení IP adres

    link

    Protokol DHCPv6 zavádí jednoznačné identifikátory klientů a serverů (DUID) a lokální identifikátory rozhraní IAID. Klientský identifikátor DUID se dá spolu s IAID použít mimo jiné ke svázání se statickou IP adresou. Tyto mapování se konfigurují na straně serveru. Za pomoci přeposílacího agenta lze veškerou konfiguraci centralizovat napříč linkovými segmenty. Výchozí adresou DHCP serveru v agentech je ff05::1:3, tedy místní multicastová adresa, která má vést na všechny servery, které se na síti starají o DHCP.

    Je třeba zdůraznit, že DHCPv6 vychází z toho, že DUID je jediným unikátním identifikátorem klienta a dvojice DUID+IAID tudíž jediným unikátním identifikátorem klientského rozhraní. To znamená, že DHCPv6 nepodporuje přidělování IP adres podle MAC adres ani podle názvů počítačů, což je jedna z těch podstatnějších změn oproti DHCPv4. To jednoduše znamená, že staré postupy přestávají fungovat.

    Myšlenka DUID jako stabilního identifikátoru napříč restarty se zdá být velmi dobrá. Zatím ale pokulhávají některé implementace, zvláště pak ty, které generují DUID a ukládají ho do diskového souboru. Vzhledem k tomu, že naprostá většina klientů jsou desktopy či laptopy s integrovaným síťovým rozhraním, nic nebrání tomu, aby se jako DUID počítače používala MAC adresa této síťové karty. Stačí k tomu donutit implementátory.

    Ale ani v ideálním případě, kdy DUID je stálý identifikátor, nelze přidělování IPv6 začlěnit do běžného workflow IPv4, kde spojujete IP adresu vždy s MAC adresou připojovaného rozhraní (třeba bezdrátového). Pak nezbývá, než překopat workflow, získat MAC adresu nějakým šikovným trikem, nebo přesvědčit IETF k doplnění standardu (a následně implementátory k doplnění implementací). Zajímavý popis situace najdete například na mailing listu dhcp-users.

    Než se implementace (a možná i standardy) více usadí, můžou se vám stávat různé neočekávané průšvihy, jako je změna DUID po reinstalaci či dokonce během síťového bootování. Hodně špatná implementace DHCPv6 klienta může měnit DUID po restartu či dokonce za běhu. Obecně narazíte častěji na problémy s klienty než se servery (i kdyby jen proto, že server se lépe mění).

    Dotaz na informace aneb bezstavové DHCP

    link

    I koncový stroj konfigurovaný bezstavově nebo dokonce ručně může použít služby DHCP serveru. Posílá pak jednoduchý dotaz na informace (information request), na který server odpovídá a požadované informace pošle. Někdy se tomu říká bezstavové DHCP (aby v tom byl ještě větší guláš).

    Delegace prefixů

    link

    DHCPv6 řeší i problém, který přichází s návratem k veřejným adresám v době IP maškarády. Koncoví uživatelé jsou zvyklí, že na internetovou přípojku zapojí router a ono víceméně vše funguje. Rozsah na vnitřním rozhraní je nastavený stejně jako u mnoha dalších uživatelů a na routeru je překládaný na jednu vnější veřejnou adresu.

    Na IPv6 bez IP maškarády je vždy potřeba nastavit vnitřní síti nějaký prefix, ať už je dále poskytován pomocí SLAAC nebo DHCP. Delegace prefixů (prefix delegation, RFC 3633) je doplněk DHCP, který se používá na vnějším rozhraní routeru. K běžné konfiguraci, jako je vnější IP adresa, DNS a podobné, přidává možnost konfigurace prefixů pro vnitřní rozhraní.

    Umím si představit docela pěkný redundantní centralizovaný systém přidělování adres postavený na DHCPv6 PD, relay agentech, centrálních serverech a třeba i OSPF.

    Závěr

    link

    Ač na adresu SLAAC padá hodně kritiky jak kvůli bezpečnosti (to se to najednou řeší po mnoha letech s IPv4), tak kvůli slabší kontrole nad samostatně konfigurovanými adresami, rozhodně bych ho nezatracoval. Naopak, nový vývoj jako SEND a RA Guard ukazují, že se na SLAAC stavět dá. A linkových adres, které jsou na samostatné konfiguraci závislé, by byla velká škoda se vzdávat (a začínat v podstatě odznovu).

    DHCPv6 má své nedostatky, když se na něj díváme z pohledu stávajících IPv4 sítí, ale stále se ještě může ukázat jako dlouhodobě lepší řešení. Nakonec nám stejně nezbyde nic jiného než vzít zavděk tím, co je, a snažit se o různé drobné opravy a vylepšení.

    Příště se podíváme blíže na routování v sítích na protokolu IPv6. Nápady a náměty pište do diskuze.

    Pavel Šimerda je lektor a konzultant z oblasti Internetu, počítačových sítí a Linuxu. Podívejte se na seznam jeho kurzů pro firmy a zvláště pak na IPv6-ready školení z oblasti sítí TCP/IP.

           

    Hodnocení: 55 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    22.6.2011 07:38 pasmen | skóre: 45 | blog: glob | Praha
    Rozbalit Rozbalit vše Re: Architektura IPv6 – konfigurace adres a objevování sousedů (2)
    Teda, vážně bych nerad, aby se nám tady rozmohla pod články reklama na soukromé kurzy autora... To je nehoráznost!
    22.6.2011 11:32 JoHnY2
    Rozbalit Rozbalit vše Re: Architektura IPv6 – konfigurace adres a objevování sousedů (2)
    Ja osobne v tom nevidim nic spatnyho. Jestli ABC smeni clanek za uplatu nebo za reklamu na konci clanku je jejich vec a pokud tenhle pristup dokaze prilakat tak kvalitni clanky jako jsou tyhle, tak jen dobre.
    22.6.2011 11:39 pasmen | skóre: 45 | blog: glob | Praha
    Rozbalit Rozbalit vše Re: Architektura IPv6 – konfigurace adres a objevování sousedů (2)
    Ten příspěvek měl značně ironický nádech, já osobně v tom totiž taky problém nevidím. Ale autor zdá se ano, proto jsem v předchozím příspěvku hodil ten odkaz, aby světlo světa spatřilo jeho pokrytectví :-)
    pavlix avatar 22.6.2011 19:48 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Architektura IPv6 – konfigurace adres a objevování sousedů (2)
    Ale autor zdá se ano,
    Divím se ti, že máš potřebu pod článkem předvádět, že umíš lidem podsouvat věci, co neřekli ani nenapsali.
    23.6.2011 09:37 pasmen | skóre: 45 | blog: glob | Praha
    Rozbalit Rozbalit vše Re: Architektura IPv6 – konfigurace adres a objevování sousedů (2)
    Nevím, čemu se divíš troubo. Nic nikomu nepodsouvám, odkaz na tvůj výrok jsem snad udal.
    pavlix avatar 23.6.2011 15:17 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Architektura IPv6 – konfigurace adres a objevování sousedů (2)
    Tvé výpady snad netřeba více komentovat.
    23.6.2011 16:58 Jan
    Rozbalit Rozbalit vše Re: Architektura IPv6 – konfigurace adres a objevování sousedů (2)
    Ten tvůj komentář je oxymoron, ne? :)
    pavlix avatar 23.6.2011 19:45 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Architektura IPv6 – konfigurace adres a objevování sousedů (2)
    Je a navíc patří mezi mé oblíbené :).
    24.6.2011 09:00 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Architektura IPv6 – konfigurace adres a objevování sousedů (2)
    Aneb jak odvést téma hovoru jinam a ještě mít pocit, že jsi zvítězil v diskuzi...
    Quando omni flunkus moritati
    pavlix avatar 24.6.2011 10:25 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Architektura IPv6 – konfigurace adres a objevování sousedů (2)
    Pokud nadávání považuješ za téma...
    22.6.2011 10:55 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Architektura IPv6 – konfigurace adres a objevování sousedů (2)
    64-bitového indentifikátoru
    Quando omni flunkus moritati
    Nicky726 avatar 24.6.2011 11:45 Nicky726 | skóre: 56 | blog: Nicky726
    Rozbalit Rozbalit vše Re: Architektura IPv6 – konfigurace adres a objevování sousedů (2)
    Hlavně 64-bitového. To bolí! A je to tam víckrát… :-(
    Enjoy the detours. There you’ll find the things more important than what you want. (Hunter x Hunter)
    pavlix avatar 24.6.2011 23:58 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Architektura IPv6 – konfigurace adres a objevování sousedů (2)
    To mě zrovna moc nebolí :). Gramaticky je to v pořádku a bez spojovníku se mi to moc nelíbí. Ale rád se nechám poučit názorem odborníka na jazyky.
    Nicky726 avatar 25.6.2011 15:09 Nicky726 | skóre: 56 | blog: Nicky726
    Rozbalit Rozbalit vše Re: Architektura IPv6 – konfigurace adres a objevování sousedů (2)
    Právě, že je to špatně. Má být 64bitový, spojovník do podobných složenin čísla a jména nepatří.
    Enjoy the detours. There you’ll find the things more important than what you want. (Hunter x Hunter)
    Luboš Doležel (Doli) avatar 25.6.2011 23:22 Luboš Doležel (Doli) | skóre: 98 | blog: Doliho blog | Kladensko
    Rozbalit Rozbalit vše Re: Architektura IPv6 – konfigurace adres a objevování sousedů (2)
    Sám tam spojovník nepíšu, ale nikdy mi to nepřišlo jako nesprávné.
    Nicky726 avatar 26.6.2011 10:09 Nicky726 | skóre: 56 | blog: Nicky726
    Rozbalit Rozbalit vše Re: Architektura IPv6 – konfigurace adres a objevování sousedů (2)
    Viz například příručku ÚČJ.
    Enjoy the detours. There you’ll find the things more important than what you want. (Hunter x Hunter)
    pavlix avatar 26.6.2011 21:01 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Architektura IPv6 – konfigurace adres a objevování sousedů (2)
    I vzhledem k tomu, že i ÚJČ jako obvykle pravido nevztahuje na všechny případy...
    Pokud místo čísla použijeme zástupná písmena x nebo n, je ustálený způsob psaní se spojovníkem: x-stupňový, n-tá odmocnina apod.
    dovolím si tvrdit, že je zbytečně přísné.

    Ale divím se, že mi neporavuješ životné klienty a takovéhle věci, které jsou podle ÚJČ taky jinak než je píšu (pravda, ony jsou podle ÚJČ jinak než je píše většina lidí v oboru.

    Takže... na 64-bitový versus 64bitový nemám až tak vyhraněný názor. Budu dál psát to první, protože se mi to líbí víc, a korektura (Luboš), ať si s tím udělá, co potřebuje.

    Jinak, komentáře typu
    Hlavně 64-bitového. To bolí! A je to tam víckrát… :-(
    v mojí hlavě často vyvolávají anglické slovní spojení „grammar nazi“. Neřeknu, kdyby to bylo napsáno jinak.

    (Když už jsme u toho, jaké uvozovky použiješ, když v českém textu dáváš do uvozovek anglické sousloví, jaké když je to české sousloví v anglickém textu, a co na to ÚJČ?)
    Nicky726 avatar 26.6.2011 21:27 Nicky726 | skóre: 56 | blog: Nicky726
    Rozbalit Rozbalit vše Re: Architektura IPv6 – konfigurace adres a objevování sousedů (2)
    S líběním je to těžký, holt ty časy, kdy se líbilo to správné, zdá se minuly. Spíš mi trochu vadí postoj: „vím, jak je to dobře, ale udělám to špatně.“

    Člověk by se, dle mě, měl snažit o dokonalost. Asi jí ze své podstaty nemůže dosáhnout, ale to neznamená, že by se neměl snažit. Ale chápu, že to každý takhle nevidí. I když si myslím, že to je škoda.

    Řekl bych, že do českého textu patří české uvozovky. Ale jestli to je jinak, rád se poučím a své chyby napravím.
    Enjoy the detours. There you’ll find the things more important than what you want. (Hunter x Hunter)
    pavlix avatar 26.6.2011 21:43 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Architektura IPv6 – konfigurace adres a objevování sousedů (2)
    S líběním je to těžký, holt ty časy, kdy se líbilo to správné, zdá se minuly. Spíš mi trochu vadí postoj: „vím, jak je to dobře, ale udělám to špatně.“
    Takový postoj naštěstí nezastávám.
    Člověk by se, dle mě, měl snažit o dokonalost. Asi jí ze své podstaty nemůže dosáhnout, ale to neznamená, že by se neměl snažit. Ale chápu, že to každý takhle nevidí. I když si myslím, že to je škoda.
    Snažit se o dokonalost s poučkami z ÚJČ je zhola nemožné.

    Navíc dávám přednost jiným božstvům.
    Řekl bych, že do českého textu patří české uvozovky. Ale jestli to je jinak, rád se poučím a své chyby napravím.
    Jestli jsem tě správně pochopil, tak bys uvozovky řídil podle vnějšího textu. S tím bych souhlasil.
    pavlix avatar 26.6.2011 21:48 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Architektura IPv6 – konfigurace adres a objevování sousedů (2)
    Člověk by se, dle mě, měl snažit o dokonalost.
    Jinak, pokud bych se snažil o dokonalost, trval bych na svojí verzi, se kterou jsem spokojený a nedovolil bych publikovat článek jinak do té doby, než změním názor :). Takže... ono to trvání na dokonalosti má taky své nevýhody.

    Ale kdysi mi tu na Abc někdo zkorigoval text ve stylu děkuju→děkuji, nacož jsem vyloženě alergický. Tenkrát jsem slušně upozornil, že to už je přehnaný zásah do stylistiky a že si to propříště nepřeju (ale ani tak jsem netrval na navrácení do „dokonalé“ podoby).
    28.6.2011 15:44 David Jaša | skóre: 44 | blog: Dejvův blog
    Rozbalit Rozbalit vše Re: Architektura IPv6 – konfigurace adres a objevování sousedů (2)
    Ať jde ÚJČ někam. Mě se to bez spojovníku blbě čte a proto to budu psát i s ním dál.
    pavlix avatar 28.6.2011 21:06 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Architektura IPv6 – konfigurace adres a objevování sousedů (2)
    msk avatar 22.6.2011 11:26 msk | skóre: 27 | blog: msk
    Rozbalit Rozbalit vše Re: Architektura IPv6 – konfigurace adres a objevování sousedů (2)
    Presiel som to zbezne a mudrejsi nie som. Asi si to budem musiet precitat niekolko krat po sebe. Inak pri nasavani informacii o IPv6 sa u mna dostavuje ten melancholicky pocit, ze som sa vratil v case do svojich pubertalnych cias, ked som zacal objavovat veci ako ip adresa, maska, router, dns, proxy, dhcp a nicomu z toho som vobec nerozumel.
    22.6.2011 11:43 JoHnY2
    Rozbalit Rozbalit vše Re: Architektura IPv6 – konfigurace adres a objevování sousedů (2)
    Mam uplne stejny pocity ... a docela chapu proc si kamarad v praci buduje IPv6 sit ve volnejch chvilich. Bez slusny davky praktickejch zkusenosti budeme pekne v loji pratele moji.
    22.6.2011 12:20 Sten
    Rozbalit Rozbalit vše Re: Architektura IPv6 – konfigurace adres a objevování sousedů (2)
    Ono si to asi chce vyzkoušet, mě stačilo jedno odpoledne na nasazení IPv6 sítě přes tunel a pochopení základů a na tom se dá už dobře stavět.
    22.6.2011 15:12 Mortal | skóre: 26 | blog: mortals_log
    Rozbalit Rozbalit vše Re: Architektura IPv6 – konfigurace adres a objevování sousedů (2)
    autokonfigurace, dhcp, multicasty, anycasty nejsou pro jednoduche pouziti vubec potreba, mozna u velkych siti se to bude hodit
    Ja ipv6 pres tunely pouzivam uz mnoho let stejnym zpusobem jako ipv4 a jsem spokojenej :)
    V pekle jsou samé diskety a ďábel je velká disketová mechanika
    27.6.2011 20:56 Sten
    Rozbalit Rozbalit vše Re: Architektura IPv6 – konfigurace adres a objevování sousedů (2)
    Autokonfigurace je pro jednoduché sítě právě naprosto úžasná a přijde mi jednodušší než IPv4 DHCP. Jenom na routeru rozběhnu radvd (+ bezstavové DHCPv6, pokud tam budou Windows) a celá síť funguje :-)

    Multicast se většinou používá automaticky (místo broadcastu nebo pro mDNS, Avahi ap.), ale třeba doma jsem jej používal i pro vysílání televize. Anycast je spíše pro Google a spol.
    22.6.2011 15:15 Yenya
    Rozbalit Rozbalit vše bezpecnost SLAAC
    na adresu SLAAC padá hodně kritiky jak kvůli bezpečnosti (to se to najednou řeší po mnoha letech s IPv4),
    Ne, u IPv4 tohle nikomu nevadi, protoze takove pripady maji frekvenci (v me siti) jednou za nekolik let, a ma tedy cenu toho jednoho konkretniho uzivatele dohledat a jemne ho upozornit. Navic takovy problem vznikne vzdy chybou uzivatele nebo zlym umyslem, takze je korektni striktne po uzivateli pozadovat napravu.

    U IPv6 je to jine kafe - tam tenhle problem generuji kazde druhe Windows, ktere maji zapnuty connection sharing. A to u mnohych siti fakt nemuzete resit pripad po pripadu, protoze ti uzivatele neudelali nic spatneho - maji implicitni konfiguraci svych Windows (tedy: to je spatne samo o sobe, ale to je jiny problem :-).

    Cili nejde (az tak) o problem bezpecnosti, ale o to ze tento problem je u IPv6 v polovine Windowsovych notebooku, ktere vam prijdou do site.

    -Yenya, http://www.fi.muni.cz/~kas/blog/
    pavlix avatar 22.6.2011 19:53 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: bezpecnost SLAAC
    U IPv6 je to jine kafe - tam tenhle problem generuji kazde druhe Windows, ktere maji zapnuty connection sharing.
    To zní jako kdyby Windows neuměly connection sharing IPv4.
    protoze ti uzivatele neudelali nic spatneho - maji implicitni konfiguraci svych Windows
    S tím bohužel nemůžu souhlasit.

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.