IPv6 - nový Internet

7. 3. 2008 | Pavel Šimerda | Sítě | 28653×

Počítače současného Internetu spolu komunikují převážně pomocí protokolu IPv4. Tato verze sloužila dlouho a prokázala svoji robustnost a použitelnost. Přesto se už dlouhou dobu projevují její omezení. A bude už jenom hůř.

Největším kamenem úrazu IPv4 (RFC 791, Internet Protocol version 4, z roku 1981) je 32bitový adresový prostor. Každý počítač na Internetu má svou veřejnou IP adresu. Takových počítačů může být teoreticky okolo čtyř miliard. Takové číslo zní hezky, ale nezapomeňte, že některé rozsahy jsou vyhrazeny specifickým účelům a jiné jsou přidělené organizacím, které je zdaleka nevyužívají. Rovněž se rozšiřuje množství různých jednoúčelových zařízení s vlastní IP adresou (tiskárny, kamery, síťové disky a další).

Protože je změna velikosti adresového prostoru velmi náročná a drahá, hledala se nejdřív opatření, která se obejdou bez ní. Jedním z nich bylo zavedení agregace po bitech místo po třídách, které nabízely adresový prostor jednoho až tří celých bajtů (RFC 4632, Classless Inter-Domain Routing). Toto opatření problém výrazně oddálilo. Jedinou další možností, jak získat z IPv4 prostoru další adresy, je začít odebírat rozsahy subjektům, které je nevyužívají. Nejenže by to opět jen oddalovalo řešení, ale navíc vyvolalo negativní reakci dotyčných subjektů.

Za dnes velmi populárním způsobem obcházení nedostatku adres stojí myšlenka, že není potřeba přidávat tolik dalších počítačů a zařízení na Internet. Počítá s konzumním modelem využívání Internetu, při kterém koncový uživatel buď musí za jednotlivé adresy platit (pokud jsou vůbec k dispozici), nebo se musí spokojit s tím, že jeho počítač není součástí veřejného Internetu. Takovému přístupu se pak říká IP maškaráda nebo zjednodušeně (a mnohem častěji) NAT. Adresování vnitřní sítě se pak řeší některým z privátních rozsahů (RFC 1918, Address Allocation for Private Internets). Pokud má zákazník to štěstí, že má aspoň jednu veřejnou IP adresu, může směrováním portů a dalšími technikami obcházet omezení, které absence dalších veřejných adres způsobuje.

Asi nepřirozenějším řešením je použít novou verzi IP (RFC 2460, Internet Protocol, Version 6). Ta nám, kromě zvětšení adresového prostoru, přinese i další vylepšení a zjednodušení. Na druhou stranu nám přinese problémy spojené s přechodem od IPv4 k IPv6 a také s provozováním obou sítí zároveň (což jistě bude na dlouhou dobu nutnost). Nová verze protokolu řeší stejné problémy a slouží stejnému účelu jako předchozí, ale je lépe přizpůsobena dnešní podobě Internetu a především jeho rozsahu. Proto také zachovává většinu rysů původního IP protokolu, některé jen mírně vylepšuje.

Struktura paketu

Hlavička IPv4 paketu zabírá 160 nebo více bitů (20 nebo více bajtů), podle počtu rozšiřujících polí (Options) a zahrnuje, mimo jiné, dvě 32bitové adresy, verzi protokolu, velikost hlavičky, informace o fragmentaci a velikost paketu. IPv6 zabírá vždy 320 bitů (40 bajtů), což není tak zlé, vzhledem ke čtyřnásobným (128bitovým) adresám. Odpadají informace o fragmentaci, stejně už se dnes fragmentují pakety v koncových bodech a ne na routerech. Také samozřejmě odpadá délka hlavičky a místo pole Protocol se používá Next Header, které navíc umožňuje vkládat rozšiřující hlavičky (náhrada za options). Zajímavostí je, že se nepoužívá kontrolní součet hlavičky, ale spoléhá se na linkovou vrstvu. Tím se zjednodušuje práce routerů, které ho už nemusí přepočítávat kvůli změnám pole Hop Limit (dříve TTL, počet uzlů, do kolika smí paket při pokusu o doručení ještě vstoupit).

Zdroj obrázku Wikipedia, licence FDL.

Adresování sítí

Už víme, že je IPv6 adresa dlouhá 128 bitů (počet možných adres, porovnávání s počtem hvězd ve vesmíru a podobné hříčky přenechám čtenáři). Taková délka umožňuje adresy lépe strukturovat. Adresy uzlů se zapisují jako skupina osmi 16bitových hexadecimálních čísel oddělených dvojtečkami.

2001:0db8:85a3:08d3:1319:8a2e:0370:7344

Adresy sítí se zapisují stejně, jen se na konec přidá lomítko a počet společných bitů, ostatní se dávají nulové (následující dva zápisy označují stejnou adresu).

2001:0db8:85a3:08d3:0000:0000:0000:0000/64
2001:0db8:85a3:08d3::/64

Adresa uzlu se dá rovněž zapisovat společně s adresou sítě.

2001:0db8:85a3:08d3:1319:8a2e:0370:7344/64

Nevýznamové nuly se mohou vynechávat, jeden blok nulových čísel jde nahradit čtyřtečkou (i na začátku nebo na konci adresy). Následuje několik různých zápisů téže adresy.

2001:0db8:0000:0000:0000:0000:1428:57ab
2001:0db8:0000:0000:0000::1428:57ab
2001:0db8:0:0:0:0:1428:57ab
2001:0db8:0:0::1428:57ab
2001:0db8::1428:57ab
2001:db8::1428:57ab

Adresy se přidělují jednotlivým síťovým rozhraním, ne uzlům a dělí se na tři typy: unicast (adresa s jedním konkrétním cílem), anycast (adresa, která slouží k nalezení nejbližšího odpovídajícího cíle) a multicast (adresa, která slouží k dosažení celé skupiny cílů). Vedle těchto typů je také důležitý rozsah platnosti (scope); důležité jsou především globální (global) a lokální, používaný v rámci jednoho spoje (link-local). Adresový prostor je hierarchicky organizovaný (RFC 4291, IP Version 6 Addressing Architecture).

Rozdělení adresového prostoru

Z adresového prostoru IPv6 jsou vyděleny speciální adresy a rozsahy. Adresa se samými nulami (0:0:0:0:0:0:0:0 nebo zkráceně ::) se používá jako speciální hodnota a značí nevyplněnou adresu. Jedna jednička, která následuje za samými nulami (0:0:0:0:0:0:0:1, zkráceně ::1) je adresou místní smyčky (jako IPv4 127.0.0.1). Multicast má vyhrazený rozsah ff00/8, link-local unicast je fe80::/10. Ostatní adresy jsou global unicast. Na IPv6 anycast adresy jsem nezapomněl, ty se nachází ve stejném rozsahu jako unicast a zatím jsem narazil na jejich použití pouze u mobility (adresa sítě je zároveň anycast adresou jejích routerů) a redundance.

Link-local unicast adresy

Každé IPv6 rozhraní má svoji link-local IPv6 adresu, která slouží ke komunikaci s ostatními stroji na stejném ethernetovém segmentu. Ta zůstává platná bez ohledu na globální adresy. Link-local adresy se používají k routování, sdílení služeb po místní síti a dalším věcem. Při používání link-local adres nezapomeňte uvádět síťové zařízení, to nejde z adres zjistit.

Globální unicast adresy

S výjimkou speciálních (začínajících bity 000) mají druhou polovinu vyhrazenou pro 64bitový identifikátor síťového rozhraní. Takový identifikátor se získává z EUI-64 (Extended Unique Identifier) převrácením bitu, který určuje, jestli je identifikátor globálně unikátní. Rovněž je možné získat EUI-64 doplněním bajtů FF:FF doprostřed MAC-48 (ethernetová adresa) nebo FF:FE doprostřed EUI-48. Zajímavostí je, že pro účely IPv6 se i MAC-48 považuje za EUI-48. Protože tyto identifikátory sdílejí adresový prostor, nemůže to ničemu vadit. Více o automatické konfiguraci a používání EUI-64 v IPv6 se dozvíte příště.

První část adresy se typicky dělí na 48 bitů globálního routovacího prefixu, a 16 bitů pro místní rozdělování na podsítě. Zákazník tedy v lepším případě získá 48bitový prefix a zbývá mu 16 bitů pro podsítě a 64 bitů pro identifikátor rozhraní.

Multicast

Popis multicastu by vydal na samostatný článek. Multicast jednak nahrazuje dřívější broadcasty, jednak umožňuje efektivní provozování některých služeb (vysílání rozhlasových nebo televizních stanic, objevování koncových počítačů, routerů a služeb na síti.

Mobilní IPv6

Mobilita spočívá v tom, že mobilní uzel (koncový počítač) používá pořád stejnou IPv6 adresu, bez ohledu na to, ke které síti se připojí. Toho se docílí směrováním komunikace přes domácího agenta, který danou adresu obhospodařuje. Směrování přes domácího agenta se docílí přidáním routovací hlavičky (Type 2 Routing Header).

IPsec

IP security je povinnou součástí IPv6 a nepovinným rozšířením IPv4. Zajišťuje šifrování a integritu paketů, autentizaci komunikujících subjektů a ochranu proti replay útokům. Může pracovat v transportním módu (transport mode) a tunelovém módu (tunnel mode). V prvním případě se šifrují a autentizují data (autentizace si hlídá navíc adresy) a je určený ke komunikaci jednotlivých uzlů. Druhý slouží k propojování sítí a šifrují a autentizují se pak celé pakety.

Historie podpory IPv6 v některých OS

Zatímco první náznaky podpory IPv6 v Linuxu se objevují v roce 1996 (kernel 2.1.8), následované podporou v IBM AIX, Microsoft přichází s první ukázkou v roce 1998. Systémy z rodiny BSD se dočkaly v roce 2000, stejně jako Sun Solaris. Cisco nabízí IPv6 od roku 2001. Windows XP SP1 (2002) a Windows Server 2003 už počítají s jeho reálným nasazením. S povolením IPv6 ve výchozím nastavení je předběhl o čtyři roky Apple Mac OS X Panther (2003), než přišly Windows Vista (2007).

Zajímavosti

Vlády některých zemí (například USA) vyžadují od sítí svých úřadů připravenost na IPv6. Zajímavým hráčem na tomto poli je také Čína. Zatímco USA má zhruba třetinu IPv4 prostoru, v Číně je více uživatelů vysokorychlostního Internetu než veřejných IPv4 adres. Svoje síťové schopnosti chtějí předvést na letošních letních olympijských hrách, kde plánují k sesíťování zařízení používat výhradně IPv6. Tuto informaci berte prosím s rezervou, mám ji jen z Wikipedie.

IPv6 URL

Tak jako existují URL, která mají místo hostname IPv4 adresu, používají se i URL s IPv6 adresou, která se ale dává do hranatých závorek (http://[2001:0db8:85a3:08d3:1319:8a2e:0370:7344]/cesta/k/něčemu, https://[2001:0db8:85a3:08d3:1319:8a2e:0370:7344]:443/). Podobně je to samozřejmě i u jíných protokolů než HTTP a HTTPS.

Co nás čeká příště?

Už jsem prozradil, že se podíváme na automatickou konfiguraci IPv6 adres. Ta je však velmi jednoduchá. Mnohem více se budeme zabývat tunelováním IPv6 po stávající infrastruktuře, protože velká část z vás nemá přístup k nativní IPv6 síti.

       

Komentáře

[Michal Ludvig]

Obávám se že pro člověka který o IPv6 nic neví, což je nejspíš cílová skupina článku, je to povídání jen seznamem povětšinou nevysvětlených termínů pod kterými si nedokáže nic moc představit...

Nedá mi to abych si zde nepřihřál svou polívčičku, byť již pár let uleželou: IPv6 krok za krokem

[Creckx]

A co by si chtěl? Je to jen "upgrade" starýho protokolu, principiálně se nic nemění.

[pavlix]

Klidně přihřej :).

Pro člověka, který zná dobře IPv4 už není IPv6 zase tak náročná změna.

[Stanislav Petr]

To mohu jen potvrdit. IPv6 mame realne nasazenou neco prez rok a uz jsem si na ni zvyknul tak, ze se mi s ni dela dokonce lip nez s IPv4.

[pavlix]

Tak ona je v lecčems pohodlnější, podle mě.

[Vašek Lorenc]

No přinejmenším čtení adres "od oka" by mohl být problém.. Náš IPv6 prefix už víceméně znám, ale když se objeví pár podobných, tak bych za výběr toho "správného" ruku do ohně nedal..

Plus se sem přidává celá řada bezpečnostních problémů, které s IPv4 nebývaly.. Přeci jen to je nový svět, ač se to tak docela nezdá. A hlavně mladý.

[pavlix]

Plus se sem přidává celá řada bezpečnostních problémů, které s IPv4 nebývaly.

Povídej, zatím jsem žádný nový bezpečnostní problém neobjevil.

[Vašek Lorenc]

Třeba se soukromím -- to tehdy, když se pro část IP adresy používá MAC adresa.. Tahle část může být stejná pro různé prefixy, čímž by případní poskytovatelé služeb (google, seznam) mohli dělat další statistiky nad využíváním služeb. Netvrdím, že to lidi musí rozhodně trápit, ale na zamyšlení to je. Ostatně od toho má IPv6 i Privacy Extensions..

DoS útok při dotazování se, jestli už mnou vylosovanou adresu někdo nepoužívá. Potom jsou tu problémy s implementací IPv6 stacku, které se dají očekávat. Windows Vista umí tunelovat IPv6 i dost agresivní metodou..

I pro IPv6 existuje varianta ARP spoofingu, byť se tedy nejedná o nový bezpečnostní problém, jen o variaci na staré téma.

[pavlix]

Ostatně od toho má IPv6 i Privacy Extensions..

Takže žádný problém :).

DoS útok při dotazování se, jestli už mnou vylosovanou adresu někdo nepoužívá.

Hmm, dos útoky po lokální síti :). To už se mi někde stalo :). Měl jsem nastavený logy z firewallu do konzole a zapojil jsem počítač do rozsáhlé windowsovské sítě... konzole mě nepustila ke slovu :). Jen vtipná historka.... myslím, že dos útokům po lokální síti IPv6 ani nepomůže ani neuškodí.

Potom jsou tu problémy s implementací IPv6 stacku, které se dají očekávat.

Problémy s implementací jsou všude a u všeho.

Windows Vista umí tunelovat IPv6 i dost agresivní metodou.

Kdekdo umí argesivně tunelovat kdeco... ať už je to skype, hamachi, na provrtávání NATů jsou tu i nějaká ta RFC.

Tunelování má často bezpečnostní úskalí, malá zmínka je i v příštím díle (aspoň myslím). Nepočítal bych ho ani tak do bezpečnostních rizik IPv6 jako takového.

I pro IPv6 existuje varianta ARP spoofingu, byť se tedy nejedná o nový bezpečnostní problém, jen o variaci na staré téma.

Spoofovat po lokále se dá ledacos, i když ARP spoofing bych to u IPv6 úplně nenazýval... ale různému falšování identity strojů na lokálním segmentu se nezabraňuje úplně jednoduše a zadarmo.

[Vašek Lorenc]

Musím uznat, že s tímhle přístupem je v podstatě jakýkoliv problém jen drobností.. To, že IPv6 má něco ve specifikaci, ještě neznamená, že to musí všichni používat (viz oblíbený IPSec nebo problémy s mobilitou).

Ale aby se to netáhlo donekonečna -- většina těch problémů je řešitelná, případně se řeší. Je to prostě o tom, že IPv6 je mladé. Ale bylo by dost pošetilé tvrdit, že je bez chyby -- ať už specifikace, implementace, nebo způsob nasazování.

[pavlix]

Spousta IPv6-related RFC už je v nějaké třetí generaci...

A část z nich ještě čeká nějaký ten update... ale celkově na mě dělá dojem velmi kvalitního následníka stávající verze. A připadá mi, že většina z pozdějších úprav právě směřuje od té ideální teorie k praktickému použití a možnosti napravení případných side-efektů.

Rád se dozvím i o dalších rizicích ohledně bezpečnosti a soukromí... další informace dohledám sám... a mohlo by se povést zahrnout to do některého z pokračování.

[thingie]

No, to sice je, ale celý to ještě nějak extra dodělaný a masově ozkoušený není.

[pavlix]

Na to je ještě spousta času, ne? :)

Zatím si s tím hrajou technicky nadanější jedinci (a znich ještě jenom ti, kteří na to mají čas a chuť).

Aspoň teda v Česku to platí.

[thingie]

No, možná. Asi mě třeba trochu znepokojuje, že ještě v roce 2008 v univerzitní síti nemam k dosažení žádné IPv6, kterým bych bez tunelů někam dosáhl. To už by třeba jako být pomalu i mohlo.

[Vašek Lorenc]

Ono je to těžké -- ani univerzity nemusejí mít dostatečně vhodný HW pro pořádný provoz IPv6 (byť třeba pouhé routování je pochopitelně proveditelné na PC, případně na vhodně akcelerovaném PC). Univerzity občas totiž mají dost tlusté linky..

Navíc jsou i v univerzitním prostředí semo-tamo firewally, které se s IPv6 nemusí kamarádit, občas se správcům jednotlivých fakult nemusí chtít protahovat IPv6 až k nim..

Ten čas je v tomhle případě dost důležitý, stejně jako peníze na vybavení. To, že to CESNET podporuje, spoustu věcí urychlí, ale je to takový ten první (byť nesporně důležitý) krok.

[pavlix]

Právě na univerzitách si myslím, že to už mělo dávno být.

[Vašek Lorenc]

Ano, názor je to dobrý.. ale jak říkám, praktická realizace je trošku komplikovanější.

Obvykle to na páteřích univerzit k dispozici bývá, otázkou je, jak k tomu přistupují jednotlivé další části (fakulty, katedry..).

[pavlix]

U nás na matfyzu považuju absenci IPv6 za ostudu :(.

[vhor]

"Žádejte u svého správce sítě." Kde konkrétně není?

[thingie]

Já vím, že je to těžké, ale kde jinde by to mělo být, když ne na univerzitách Dokud to i tady bude ve stavu ,jo, chtěli bychom, ale nemáme na to čas a nechce se nám shánět peníze na nové krabice`, tak to bude špatný

[Vašek Lorenc]

Tahle debata už se lehce stáčí bokem.. Ono nasazování IPv6 přeci není jen poskytnutí IPv6 klientům. Bylo by dobré mít na IPv6 i mailserver, webové stránky univerzity/fakult, DNS servery, připravené adresovací schéma (jak přidělovat bloky jednotlivým univerzitním částem), reakce na útoky, firewally na rozhraní univerzity, směrem ke klientům i to DHCPv6.. To všechno s dostatečnou robustností a propustností.

Jsem optimista a věřím, že se na tom pracuje (někde to i vím jistě). Jen to prostě nejde tak rychle, jak by bylo milé. I ty páteřní boxy jde nakoupit, jenže v tom rozsahu a s procesním řízením státní sféry to všechno trvá.

Stačí to tak? Buďte na univerzity hodní..

[thingie]

Bejt hodní na ÚVT? Ještě aby to O CVT už vůbec ani nemluvit.

[MJ]

DoS útok při dotazování se, jestli už mnou vylosovanou adresu někdo nepoužívá.

DoS útok? Síly asi takové, jako jeden ARP request u IPv4, ne?

[Vašek Lorenc]

U IPv6 má (při autokonfiguraci) stroj za úkol zeptat se, jestli danou IPv6 adresu nepoužívá jiný stroj na segmentu. Odpověď v podstatě očekává od kohokoliv, ať už tu adresu fyzicky opravdu má, nebo nemá. V podstatě to je DoS útok, protože stroj, který si autokonfigurací zkoušel vymyslet IP adresu, nakonec skončí bez ní, po 3 pokusech má za povinnost s "náhodným losováním" skončit.

IPv4 tenhle povinný mechanismus nemá.

[pavlix]

Tuším, že tahle povinnost platí jen při použití privacy extensions, ale to jen pro upřesnění, na věci to nic nemění.

IPv4 tenhle povinný mechanismus nemá.

Lokální ethernetový segment ti dokážu zbořit kdekoliv. A je úplně jedno, jestli na něm je IPv4, IPv6, nebo cokoliv jiného.

Pokud ho chceš chránit, musíš počítače od sebe dostatečně oddělit, na všech vrstvách, nejen IPv6, a odfiltrovat všecko nežádoucí... pak by ti podle mě nezbývalo nic jiného, než přiřadit adresy staticky nebo pomocí DHCP. Tahle možnost by na IPv4 a IPv6 probíhala stejným způsobem. Stateless je v takové síti nepoužitelná.

Tím jsme vlastně odpověděli i na otázku, proč existuje DHCPv6. Speciální případy vyžadují speciální řešení.

[Vašek Lorenc]

Pro IPv4 už umí switche často nějaké dodatečné filtrovací mechanismy (typicky Cisco umí obranu proti ARP spoofingu a záškodnickým DHCP serverům). Pro IPv6 tohle ještě není (alespoň veřejně) implementované.

Snažil jsem se jen ukázat, že rozdíly (byť drobné) tu jsou. Jinak ale souhlasím.

[pavlix]

Teď už říkáš přesně a jasně, o co jde, takhle se mi to líbí :). Zavedení bezpečnostních mechanismů pro IPv6 může nějaký čas trvat... a může to něco (nebo i docela dost) stát. To je fakt, se kterým je těžké něco dělat.

[Vašek Lorenc]

Ale je rozhodně dobré se o tom zmínit. Nic není jen černé nebo jen bílé, pro nové technologie to platí dvojnásob. Budu se těšit na další díly seriálu.

A dobře, příště budu konkrétní ;) Ale nechtěl jsem zabíhat do zbytečných detailů.. on už i ten začátek byl (z mého pohledu ;)) konkrétní -- u IPv4 si můžu vzít IP adresu a až dodatečně se zjišťuje, jestli není problém. U IPv6 se problémům snaží předcházet, má to ale jiné důsledky.

Přeji hezkou sobotu :)

[pavlix]

Díky za feedback, bude se hodit :).

I tobě přeju hezkou sobotu :).

[trekker.dk]

Taky bych řekl...

Náš administrátor shledal tento komentář závadným.

tapetující troll

Zobrazit komentář

[pavlix]

„Jo, to byli casy kdyz se nezabijeli lidi jen protoze jim nesedi dane pohlavi ale opousteli nas skutecne nemocni lide.“

Jakou hodnotu má tato reakce ve vztahu k tématu článku?

[Jendа]

Je to troll, kterému admin smazal tento komentář o zprávičce o výročí sebevraždy Aarona Swartze, a on to teď sype do náhodných starých i nových diskuzí. Asi to bude ten co tady předtím spamoval s "win11pro".

[Dan Ohnesorg]

Nejak nejsou ty adresy z prikladu pingat

From 2001:1508:1000::8 icmp_seq=1 Destination unreachable: No route

Ale jinak me propagace IPv6 tesi.

[Stanislav Petr]

No, kdyby sly, tak by to byl docela problem....

inet6num:     2001:0DB8::/32
netname:      IPV6-DOC-AP
descr:        IPv6 prefix for documentation purpose

[the.max]

tak jsi byl rychlejsi

[disorder]

tebe ten prefix sedi? mne sa zda, ze polovica je uplne ina

[pavlix]

Se ti zdá špatně :).

Je to /32 a 32 bitů je zachovaných.

[disorder]

32b = 4B

 8 16 24 32
20 01 0D B8
20 01 15 08

alebo

       8       16       24       32
00100000 00000001 00001101 10111000
00100000 00000001 00010101 00001000

ja som asi blby...

[pavlix]

Nejsi určitě zdaleka jediný, kdo se nachytal :).

[pavlix]

Teď vidím, co porovnáváš... jiná chybka, ještě...

...1508... je IP nějakýho routeru, který Danovi řekl, že nemůže najít tu cílovou IP, kterou chtěl. Pravděpodobně pingal tu, co našel v článku.

[disorder]

no jasne, to su tiez napady davat takyto vynatok z pingu

[Dan Ohnesorg]

Odchazim se stydet do krovi.

[the.max]

Anejsou to naaahodou IP adresy ktere jsou podle nejakeho doporuceni (snad i RFC) urceny prave pro demonstraci a prikady v ruznych clancich???

[pavlix]

Ale jinak me propagace IPv6 tesi.

A bude líp :). Kdyžtak můžeš napsat... pavlix(at)pavlix.net (jabber,mail).

[Michal Kubeček]

Drobné opravy a upřesnění, na co jsem narazil při prvním čtení:

• NAT není totéž co maškaráda, maškaráda je jednou z aplikací NAT
• 40 byte je 320 bitů, ne 360
• fragmentace nezmizela, jen je realizována jako (povinně podporované) rozšíření
• chybějící dvojtečky u rozsahů: fe80::/10, fec0::/10
• multicast není novinka, rozdíl je spíš v tom, že u IPv6 není broadcast samostatný typ, ale považuje se za speciální případ multicastu

[pavlix]

NAT není totéž co maškaráda, maškaráda je jednou z aplikací NAT

Jen jsem v článku upozorňoval, že se obecnější slovo NAT často (a nepřesně) používá ve významu maškarády. Díky

fragmentace nezmizela, jen je realizována jako (povinně podporované) rozšíření

Z IPv6 hlavičky zmizela.

chybějící dvojtečky u rozsahů: fe80::/10, fec0::/10

Díky.

multicast není novinka, rozdíl je spíš v tom, že u IPv6 není broadcast samostatný typ, ale považuje se za speciální případ multicastu

Tak to přesně bylo myšleno.

[MJ]

fragmentace nezmizela, jen je realizována jako (povinně podporované) rozšíření

End-to-end fragmentace zůstává (byť není pevnou součástí hlavičky), po cestě se už narozdíl od IPv4 nefragmentuje.

[pavlix]

Já jsem to pochopil tak, že se dohodne na začátku... a potom už se v hlavičce neřeší (ad e2e fragmentace). Navíc jsem měl pocit, že většina implementaci ve výchozím nastavení zakazuje "fragmentaci po cestě" i v IPv4.

Sám jsem řešil problém s o2, kde mi na routerech po cestě zřejmě zahazovali některé pakety, čímž mi znemožnili například traceroute, ale i třeba automatické zjištění MTU/MSS. MSS jsem musel měnit na routeru. Tímto jim děkuji za (v té době) nově nabité znalosti, včera se se mnou loučili poslední fakturou :).

Btw, nechce někdo ADSL modem/router... případně dialup... nějak se mi to tu hromadí?

[Michal Kubeček]

Navíc jsem měl pocit, že většina implementaci ve výchozím nastavení zakazuje "fragmentaci po cestě" i v IPv4.

IMHO v tom není záměr, spíš řada správců z neznalosti nakonfiguruje firewall tak, že propustí jen první fragment. Tj. podobný problém, jako popisujete v dalším odstavci.

[MJ]

Já jsem to pochopil tak, že se dohodne na začátku... a potom už se v hlavičce neřeší (ad e2e fragmentace).

Ne tak úplně, jen všichni musí dělat Path MTU discovery.

Navíc jsem měl pocit, že většina implementaci ve výchozím nastavení zakazuje "fragmentaci po cestě" i v IPv4.

Kdepak, dokonce vzhledem k tomu, že některé protokoly (třeba NFS) MTU discovery nedělají, je fragmentace po cestě nutnost. (Tím určitě nechci říci, že neexistují implementace, kde je rozbitá. Ehm.)

[pavlix]

Já jsem to pochopil tak, že se dohodne na začátku... a potom už se v hlavičce neřeší (ad e2e fragmentace).

Ne tak úplně, jen všichni musí dělat Path MTU discovery.

Takže v hlavičce nic, jen se může stát, že přijde ICMP Packet Too Big, nebo ne?

Navíc jsem měl pocit, že většina implementaci ve výchozím nastavení zakazuje "fragmentaci po cestě" i v IPv4.

Kdepak, dokonce vzhledem k tomu, že některé protokoly (třeba NFS) MTU discovery nedělají, je fragmentace po cestě nutnost. (Tím určitě nechci říci, že neexistují implementace, kde je rozbitá. Ehm.)

Nojo, ale aspoň TCP už se to snad obvykle řeší přes MTU discovery, ne? (aneb, když trochu upřesním předpoklady... tak se snad časem povede).

[MJ]

Takže v hlavičce nic, jen se může stát, že přijde ICMP Packet Too Big, nebo ne?

Ano, a v takovém případě buďto odesílatel pošle menší packet (což udělá TCP), nebo packet sám fragmentuje na menší a jednotlivé kousky pak mají navíc Fragment Header.

[pavlix]

Áha, takže jsem svoje pozorování zobecnil trošku moc :).

[petr_p]

Štastný to člověk, já jsem se s nimi o tom taky hádal, taky jsem nepochodil, leč není kam přejít.

[pavlix]

Jsem v tuhle chvíli na 5GHz spoji a na info.nix.cz mam v průměru ping 6 milisekund :). Neplatím takovou hromadu peněz, konektivitu mám fullduplex. Pevnou veřejnou IP jsem dostal zdarma a mám přislíbený reverzní záznam.

Paní/slečna na druhé straně linky, když jsem se konečně dovolal na technickou podporu.... jen opakovala, že "tam žádný výpadek nevidí" a zjevně neměla tušení, o čem mluvím. Nakonec mě požádala, ať si zkontroluju kontrolky na routeru... a přeinstaluju počítač, protože ho mám určitě zavirovaný.

Jinak jedno iptables pravidlo v mangle tabulce problém vyřešilo.

[petr_p]

Jsem v tuhle chvíli na

Děkuji za doporučení. Já vím moc dobře jaká je situace v místě, o které se jedná.

Paní/slečna na druhé straně linky, když jsem se konečně dovolal na technickou podporu....

To musíte použít formulář na jejich webu a pak vám odepíše mailem člověk, co dokonce umí přečíst RFC a vysvětlí vám, že je jenom informational, a tedy není pro ně závazazné odesílat ICMP Packet too Big, když se jejich PPP server pokusí zabalit paket větší než 1492 B.

Na druhou stranu je musím pochválit, že když jsem si stěžoval, že nesměrují 192.88.99.1, tak to dokázali opravit a ještě pohanit Španěly, kteří prý byli toho příčinou.

Jinak jedno iptables pravidlo v mangle tabulce problém vyřešilo.

Vím a taky mám, jenže to řeší jen TCP. Co ostatní transportní protokoly?

[pavlix]

Ostatní jsem neřešil... a dneka už neřeším nic.

Za ten ipv6 anycast děkuju :) taky jsem s tím měl jednu dobu problémy ale kašlal jsem na to.

[Lubos Kopecky]

Asi tyden si procitam clanky o IPv6 a tohle mi na prvni pohled prijde jak obslehnuty z wikiny...

[Robert Krátký]

Můžeš být konkrétnější? To je poměrně vážné obvinění, takže pokud to neříkáš jen tak, přidej prosím informace.

[Lubos Kopecky]

Sem pouzil nevhodny slova, neni to obslehnuty, jak sem napsal, slova a vety jsou specialne pro clanek stylizovane, ale treba zdroj wiki ci jiny urcite byl pouzit (napr. historie implementace IPv6 do systemu bych odhadoval) a odkazy jsou v clanku jen na RFC (nepocitaje odkaz na zdroj obrazku), takze diky tomu vzniklo moje drobne rozcarovani.

Priste s reakci vyckam do rana bileho, kdy ze mne vyprcha to drobne rozcarovani a zacnu se na to koukat strizlivejsim okem :)

[Robert Krátký]

Mě zase nedošlo, že "wiki" značí Wikipedii (proto jsem se ptal na bližší info). Čerpáno odtud patrně bylo, takže to přidám ke zdrojům.

[pavlix]

Díky... no já jsem Wikipedii používal převážně jako rozcestník... ale do zdrojů patří. Jen chci upozornit, že wikipedii jsou ty věci často popsány jenom částečně nebo nepřesně.

[pavlix]

Priste s reakci vyckam do rana bileho, kdy ze mne vyprcha to drobne rozcarovani a zacnu se na to koukat strizlivejsim okem :)

Doporučuju. A až strávíš noc prolézáním RFC... :D.

[Lubos Kopecky]

To byla prave primo i tahle noc :)

[pavlix]

To potom jo.... teďka mě napadlo... já jsem si z wikipedie hlavně půjčil tu šestkovou adresu pro příklady... jo a obrázek paketu.

[ajikdpoe]

Ok, co ja ako BFU ktory ma internet bez verejnej IPv4 adresy musim urobit, aby som sa s inym BFU na opacnej strane zeme mohol priamo spojit, napr. pomocou SSH, SIP alebo FTP servra? Podla mna je nevyhnutna nejaka podpora zo strany ISP nie? O co konkretne sa jedna? Je mozne mat neverejnu IPv4 ale verejnu IPv6? Aky je sucasne realny stav us ISP? Dakujem.

[the.max]

Pavel to urcire bude probirat v nekterem dalsim clanku, nicmene muzes se podivat na www.sixxs.net po zaregistrovani a sepsani nekolika duvodu chces IPv6 adresu a dostanes ji i kdyz jsi za NATem.

[disorder]

maju to dobre, len som zacal po pol roku registrovat nejake neprijemnosti, ktore myslim boli kvoli ich klientovi, ale k nicomu konkretnemu som sa nedopatral. teraz nedavno som po dalsom pol roku tunel znova nahodil a cakam co sa bude diat...

[pavlix]

Počkej si na příští díl :).

[Robo]

obavam sa, ze strasit s IPv6 este stale nema zmysel

[the.max]

tohle je nesmysl. IPv6 tu melo byt uz davno. Schvalne, kolik z techle "znovuobjevenych" ctyrek se rozdeli mezi lidi co jsou za ruznymi NATy??? asi moc ne... Navic pokud vudes mit doma vice pocitacu a jinych zarizeni na ktere potrebujes mit pristup ze sveta, tezko ti jen tak nekdo (tvuj provider) venuje treba 32 adres. u IPv6 dostanes domu nekolikanasobne vetsi rozsah, nez je cely nesni internet a nikde nemusis ponizene zebrat!

[Orcen]

Podle mě, neni potřeba 32 adres, stačí jedna a firewall to pak podle portu rozešle kam člověk potřebuje. Portů je dost volných, a tak můžu jednomu počítači jeden port pro ssh, dalšímu druhej a tak dále. Máme to ve firmě, jedna adres ven a podle portu se pak dostanu ne určenej počítač.

[disorder]

a ked potrebujes 2x80, 2x21 alebo 2x akykolvek iny port?

[zde]

On HTTP funguje jen na portu 80, a FTP jen na portu 21? Odkdy?

[Petr Adámek]

Od té doby, co řada firem a organizací má natolik restriktivní bezpečnostní politiku, že na svém firewallu povolují pouze provoz na velmi omezené množině portů.

[disorder]

Náš administrátor shledal tento komentář závadným.

vulgární

Zobrazit komentář

[disorder]

ujo, nebud precitliveny, ved vo vasich diskusiach sa casto vyskytuju aj "horsie" slova

viem, ze som ta minule asi nastval tym, ze som vyjadril objektivny pohlad na obsah jedneho clanku, ale mohol by si sa cez to preniest

pre archivne ucely:

Pokud je komentář extrémně vulgární, navádí k porušování platných zákonů (warez) nebo je přímo porušuje, mohou administrátoři označit komentář jako závadný. Pak obsah komentáře bude skryt, místo něj bude zobrazeno zdůvodnění administrátora.

extremna vulgarita, ROTFLMAO xD

[disorder]

a pre pripad, ze aj toto je nejak extremne vulgarne ( :D ) to preformulujem

ja hovorim nieco o protokoloch? teba je "nestráviteľné látky vylučované z ľudského tela" do toho co ja chcem robit s 2 portami s rovnakymi cislami

[zde]

Vaše porty, protokoly, stejně jako domělé i skutečné vulgarity jsou mi fuk, reagoval jsem především na sloveso "potřebuju", které jste použil aniž byste k tomu uvedl nějaký rozumný důvod.

[disorder]

dovodov by sa naslo vela, ale fakt je, ze pri ipv6 to moze byt kazdemu uplne jedno a nemusi sa starat do mojich veci!

[Robert Krátký]

ujo, nebud precitliveny, ved vo vasich diskusiach sa casto vyskytuju aj "horsie" slova

Buď to není pod články, nebo o tom nevíme.

viem, ze som ta minule asi nastval

To nebyl důvod pro cenzuru. Ostatně si na tebe nepamatuji, sorry. Každou chvíli mě někdo naštve :-).

[xm]

Jenže to je NAT, to není připojení do Internetu, jde to dokonce přímo proti základním principům Internetu.

IPv6 bude znamenat smrt všem hnusným NATům

[Michal Ludvig]

NAT je připojení do internetu pro drtivou většinu domácích i firemních uživatelů. Že před několika desetiletími předpokládali "otcové" internetu že každé dva uzly spolu budou moci přímo komunikovat je sice pěkné, ale v dnešní době to prostě neplatí. S NATem jsme se naučili docela dobře žít a stěžovat si, že NATování je proti pravidlům je už leda pro smích. Dřív nebyl rozdíl mezi servery a klienty - všichni měli stejné připojení a byli si v podstatě rovni. V dnešní době ten rozdíl je - server má veřejnou, fixní IP, klient zhusta nemá veřejnou a málokdy má fixní IP a s tímhle rozdělením se dá docela dobře fungovat. Svět se mění, Internet se mění a i ony základní principy se mění.

To je podobné jako se v debatách pořád dokola rozhohňovat že lidi říkají hacker i když mají na mysli cracker. Prostě nepřesnost která se postupem času ustálila jako nový význam, nové pravidlo. Slovo šukat taky dřív mělo úplně jiný význam než dnes, stejně tak je to s hackerem a základními principy Internetu.

BTW nezapomínej na to, že NAT, jako bonus, představuje pro vnitřní klienty docela solidní bezpečnostní vrstvu a věř tomu že i z tohoto důvodu se NAT zanedlouho začne objevovat i v IPv6 sítích.

[pavlix]

Pro většinu domácích i firemních uživatelů je internet a web to samý.

Znamená to tedy, že internet je web?

Vybral sis na komentování špatnej portál.

[Michal Ludvig]

Pro většinu domácích i firemních uživatelů je internet a web to samý. Znamená to tedy, že internet je web?

Nemyslím že jsem něco podobného říkal. Ale když už jsme u toho... drtivá většina uživatelů má na stole počítač který se chová jako klient a ten když má dělat něco rozumného připojí se k serveru. Takhle to funguje s webem, s mailem, umí tak fungovat většina IM i herních protokolů, fungují tak fileservery, printservery a všechnyostatníservery. Komunikace klient-klient naproti tomu není zdaleka tak obvyklá jako klient-server a až na několik výjimek se bez ní dá obejít. Ty výjimky jsou buď pitomě navržené protokoly, které v případě že nefunguje klient-klient komunikace nemají fallback na klient-server (jakkoliv uznávám že v některých případech by tento fallback mohl mít vliv na efektivitu komunikace). Druhý případ výjimek jsou situace kdy jedna strana ve skutečnosti vystupuje jako server a nikoliv jako klient, což může být třeba v případě že se někdo chce na můj desktop připojit přes SSH nebo přes některý z remote desktop protokolů. Naštěstí ve většině případů (bavme se o reálném světě, nikoliv o vašem zbožném přání) tahle situace nastává jen v rámci interní NATované sítě kde každý vidí každého. Takže v rámci mé sítě se můj desktop může chovat jako server i klient zároveň a směrem do Internetu jen jako klient. A až na VoIP mi nejspíš bude všechno fungovat jak má.

Jistě by bylo pěkné, v případě že chci třeba provozovat doma veřejně přístupný server, mít možnost dostat pro něj od providera vyhrazenou fixní adresu. Že tohle často není možné ale není ani chyba IPv4 ani chyba NATu ale chyba těch providerů.

Vybral sis na komentování špatnej portál.

Ale jdi ty chytrolíne

[Michal Kubeček]

umí tak fungovat většina IM i herních protokolů

Ale za jakou cenu?

fungují tak fileservery, printservery a všechnyostatníservery

Máte velmi omezenou představu o tom, co všechno Internet nabízí a hlavně co by mohl nabízet. Tomu se ale bohužel nelze divit, právě dnešní neutěšená situace zamaškarádovaných "klientů" k takovému deformovanému vnímání Internetu vede.

Že tohle často není možné ale není ani chyba IPv4 ani chyba NATu ale chyba těch providerů.

Je to chyba IPv4; adresní prostor IPv4 je nedostatečný a ví se to už nejméně 15 let. Nelze to vyčítat jeho původním architektům, protože těžko mohli předpokládat, že jejich projekt někdy nabyde dnešních rozměrů, a kdyby hned na začátku navrhli např. 64-bitové adresy, bylo by to při tehdejších hardwarových prostředcích příliš nepraktické. Chybou je pouze to, že se ještě dnes IPv4 používá pro téměř veškerou komunikaci.

[Majkls]

drtivá většina uživatelů má na stole počítač který se chová jako klient a ten když má dělat něco rozumného připojí se k serveru.
Drtivá většina uživatelů používá p2p sítě. Jinak NAT jako security feature je nesmysl. Je to to samý, jako když dám do iptables 2 pravidla:

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -j REJECT

Jenže to strašně degraduje původní myšlenku. Nat slouží akorát k anonymizaci, zabezpečení je vedlejší produkt (IPv6 má pro anonymizaci privacy extensions). Nebo snad někdo chce tvrdit, že zombie počítače jsou jen za na veřejných IP? Sám jsem zažil několikrát situaci, kdy 2-3 kousky těhle strojů (za natem) málem sundaly routery. Po praktických zkušenostech vím, že nat nestačí. Je třeba udělat ještě pár pravidel na filtrování portů. Nehledě nato, že nat je hrozná brzda.

[Michal Kubeček]

Jinak NAT jako security feature je nesmysl. Je to to samý, jako když dám do iptables 2 pravidla:

Naopak, maškaráda ochrání síť podstatně méně než tato dvě pravidla. Tato pravidla zabrání navázat spojení zvenku. Maškaráda sama o sobě ne.

[MJ]

Právě VoIP je krásný příklad toho, jak příšerná berlička takový NAT je a že snažit se tomu přizpůsobovat všechny protokoly je cesta do /dev/hell.

[Robert Krátký]

Vybral sis na komentování špatnej portál.

Je tohle nutné? Doporučuji trochu více tolerance nebo aspoň diplomatičnosti.

[pavlix]

Ale jo, trochu tolerance to chce, pardon.

[xm]

Ne, NAT opravdu není připojení do Internetu. Stejně jako World Wide Web není Internet, ač pro naprostou většinu běžných uživatelů to znamená jedno a to samé. Nesmírně doufám, že lidí s tak omezeným názorem, jaký máte vy, je minimum. To co předvádíte je degradace Internetu a já pevně doufám, že IPv6 tomu učiní přítrž.

Jinak NAT není firewall a ani jím nemá být. Ta "bezpečnost", kterou podle vás NAT poskytuje, je jen a pouze iluze. Není žádný důvod pro to, aby se v IPv6 sítích používal NAT. Od bezpečnosti je tu jak už jsem psal firewall. A poskytovatel připojení klidně na jejich routerech může vlastní firewall používat, dokonce ho třeba může zákazníkům nabídnout jako službu navíc za příplatek, jak je libo. Firewall v žádném případě nevyžaduje NAT.

[jdobry]

Omyl! NAT sice na zabezpeceni site zdaleka nestaci, ale slusne zabezpeceni site bez NAT neudelate.

Jednoduse proto, ze nechcete zverejnovat informace z vnitrni site za firewalem ven. Nechcete celemu svetu sdelovat kolik mate pocitacu. Nechcete celemu svetu sdelovat kdy je ktery pocitac zapnut. Nechcete celemu svetu zdelovat ze pouzivate zarizeni konkretniho vyrobce jednoduse pomoci IP adresy (MAC je soucasti autoconf IPv6)

[Majkls]

tak proto se nechá použít privacy extensions, že...

[jd]

"privacy extensions" neni 100% reseni problemu. Jedine ve polupraci s proxy, ale to lze jen u nekterych protokolu. Jinak stale unikaji informace ven.

[pavlix]

Existuje jen jedno 100% řešení (každý asi uhodne jaké).

Jinak je myslím lepší řešit skutečné problémy a ne tvořit problémy, aby nějaké byly.

[pavlix]

Nechcete celemu svetu zdelovat ze pouzivate zarizeni konkretniho vyrobce jednoduse pomoci IP adresy (MAC je soucasti autoconf IPv6)

Doporučuju pročíst i privacy extensions. Pokud je zapneš, netýká se tě ani počet počítačů, ani MAC adresy.

[Michal Ludvig]

To co předvádíte je degradace Internetu

Nikoliv, to co předvádím je popis reality.

Jinak NAT není firewall a ani jím nemá být. Ta "bezpečnost", kterou podle vás NAT poskytuje, je jen a pouze iluze.

Tohle je oblíbené tvrzení které mi zatím nikdo uspokojivě nevysvětlil. Můžete být můj první

Řekněme že chcete zabránit útoku z venku na počítač v interní síti. Pokud máte NAT není ta interní IP přímo adresovatelná z venku takže útočník musí nejdřív získat kontrolu nad NATovadlem a odtamtud se teprve dostat na váš interní stroj. Čili hlavní obrana bude ležet na přístupu na NATovadlo (v případě linuxu to bude v iptables INPUT chain plus patřičné aplikace jako ssh).

Pokud na druhou stranu má interní stroj veřejnou IP tak se útočník z venku může rovnou pokusit o přístup. Jistě že máte firewall, ale na jeho ochranu musíte vynaložit úplně stejné úsilí jako v případě NATovadla, protože jakmile se útočník dostane na FW bude mít přístup do vnitřní sítě. Ovšem navíc se musíte zabývat forwardovacími pravidly firewallu. I když zakážete veškerý provoz ve směru do vnitřní sítě, stále může dojít k situaci kdy v implementaci iptables FORWARD chainu bude chyba která umožní tohle blokování nějakým způsobem prolomit bez toho aby útočník musel přímo získat kontrolu nad firewallem.

Takže NAT opravdu z principu své funkce funguje jako efektivní (nikoliv jediná) vrstva v ochraně sítě.

Pokud stále trváte na svém výše uvedeném tvrzení že bezpečnost kterou NAT poskytuje je jen iluze tak prosím předložte nějaké argumenty.

[Franta Gajdůšek]

Nat jde prostrelit pres pakety smerovane zdrojem, kterym se da adresa natovaciho stroje jako brana a cilova adresa adresa pocitace ve vnitrni siti. Ale v kazdem pripade je to o neco obtiznejsi. Bezpecnost natu neni ani iluze ale ani neni tak velka jak si nekteri predstavuji.

[Michal Kubeček]

Nat jde prostrelit pres pakety smerovane zdrojem

Pokud je útočník ve stejném segmentu jako brána (což v mnoha případech nelze vyloučit), nepotřebuje ani ten source routing.

[Michal Vyskočil]

A tento typ útoků je doménou zaplevelených Windows, kde se červi musí řadit do fronty, aby vůbec mohli odeslat paket. A hodný NAT "chránící" uživatele je naprosto k ničemu

[Michal Ludvig]

Naštěstí lze source routing jednoduše zakázat.

[pht]

Pak uz ale plnite funkci firewallu.

[David Jaša]

... a NAT je tam co do bezpečnosti akorát na ozdobu.

[pavlix]

+1 :)

[Xerces]

Slovo šukat má pořád stejný význam. Maximálně se přidal další. NAT je krok z nouze a je to krok určitě špatným směrem. Ano všechno se vyvíjí, ale ne vždy k lepšímu. Taky už nechci žebrat za každou IP u providera jak socka.

[Michal Kubeček]

Že před několika desetiletími předpokládali "otcové" internetu že každé dva uzly spolu budou moci přímo komunikovat je sice pěkné, ale v dnešní době to prostě neplatí.

Jenže je to zdrojem četných problémů a důvodem k vymýšlení neuvěřitelně krkolomných a místy až absurdních řešení, kdy spolu nezřídka dva počítače v jednom ethernetovém segmentu komunikují přes server na druhém konci světa. Maškarády mají sice zásluhu na zpomalení vyčerpávání adresního prostoru IPv4, ale to je vykoupeno tím, že významnou měrou přispěly k oddalování skutečného řešení problému.

V dnešní době ten rozdíl je - server má veřejnou, fixní IP, klient zhusta nemá veřejnou a málokdy má fixní IP a s tímhle rozdělením se dá docela dobře fungovat.

Jistě. Třeba pro VoIP komunikaci je to velice praktické uspořádání…

BTW nezapomínej na to, že NAT, jako bonus, představuje pro vnitřní klienty docela solidní bezpečnostní vrstvu

Na to nelze zapomínat, protože to především vůbec není pravda. Maškaráda (ani jiná aplikace překladu adres) nebrání přístupu do vnitřní sítě, to je jen hojně rozšířený omyl. Přístupu do té sítě brání filtr a bude mu bránit i bez maškarády.

věř tomu že i z tohoto důvodu se NAT zanedlouho začne objevovat i v IPv6 sítích

Stále věřím, že tomu tak nebude. IMHO lze např. označní site-local adres jako deprecated chápat jako signál, že v tomto ohledu nejspíš výjimečně zvítězí zdravý rozum nad hloupými návyky.

[the.max]

co to placas za nesmysly??? Internet je prave presne o tom, ze kterikoli 2 lidi kdekoli na svete mohou spolu komunikovat primo a ne prez nejakeho prostrednika. NAT vznikl prave kvuli tomu, ze zacal byt nedostatek IP adres. Pravda je, ze vetsinou se to da zkousnout, ale jsou pripady kdo proste ty verejny IPcka potrebuju a prijde mi fakt dost ponizujici, zadat u svyho providera o prideleni 4 Ip adres a do zadosti rozepisovat duvody proc je potrebuju, proc jich potrebuju tolik a proc mi nestaci jen tan forward portu!!!!!!! Prave kvuli tomu tu IPv6 melo byt uz davno. Zrovna minule pondeli mi zakaznik poslal pozadavek na 4 verejne IP adresy, zadost jsem trochu lepe zformuloval a predal ji svemu providerovi, ten mi ji zamitl s tim, ze on ma jiz vycerpan "rocni pridel" a ze mam smulu.Vis jak jsem tento problem musel vyresit? ospovil jsem dalsiho providera od ktereho dostanu dalsi adresy. neni to postavene na hlavu??? A to je jen kvuli takovym lidem jako ses ty, kteri obhajuji takovou prasarnu jako je NAT!

[Michal Ludvig]

A to je jen kvuli takovym lidem jako ses ty

Fííííha, lidi už mi připisovali lecjaké zásluhy, ale nedostatek IPv4 adres zatím nikdo! Jsem oslněn a poctěn Jdu spát...

[zde]

> Internet je prave presne o tom, ze kterikoli 2 lidi kdekoli na svete mohou spolu komunikovat primo a ne prez nejakeho prostrednika. NAT vznikl prave kvuli tomu, ze zacal byt nedostatek IP adres.

Před cca 10 lety jsme ve firmě každý vývojářský desktop měli na veřejné IPv4 adrese, navíc velmi "řídké", protože v 5 lidech jsme jen pro sebe (servery byly jinde) měli celou půlku céčka (tj 126 adres). Nedostatek IP adres se nás tedy netýkal, přesto ta vaše idea "přímé" komunikace nefungovala. Podle network policy byl na celém subnetu stavový FW, a příchozí spojení bylo filtrováno. Přestat filtrovat vybrané adresy nebo porty bylo považováno (imho zčásti oprávněně) za bezpečnostní riziko.

Tím chci jen ukázat, že konec end-to-end konektivity nemá s NATem téměř nic společného, protože nastal mnohem dříve, než se nedostatek adres vůbec začal projevovat. NAT řeší reálný problém (nedostatek adres), výměnou za featuru, která byla už stejně dávno mrtvá.

[David Jaša]

Potřeba end-to-end konektivity přišla až s voip, IM a p2p sítěmi, které se začaly rozmáhat až po nástupu NATů. S možností plné konektivity pak není problém přizpůsobit firewally tak, aby dané věci pouštěly (například v SOHO krabičkách pár zaškrtávadly "povolit telefon" apod).

[petr_p]

FTP tu bylo mnohem dřív.

[Ondrej 'SanTiago' Zajicek]

Potřeba end-to-end konektivity přišla až s voip, IM a p2p sítěmi, které se začaly rozmáhat až po nástupu NATů.

Treba tradicni talk (jehoz historie saha nekam do pulky osmesatych let) vyzaduje take end-to-end konektivitu.

[David Jaša]

Klíč je v tom "se začaly rozmáhat". Možná jsem měl napsat "se začaly ve velkém rozmáhat".

[pavlix]

Tak ve velkém se nám rozmáhá tak web a mail :D. Možná ještě MSN :D.

[petr_p]

Je ovšem rozdíl nechat si uříznout nohu a narodit se bez nohy.

[Michal Kubeček]

Nedostatek IP adres se nás tedy netýkal, přesto ta vaše idea "přímé" komunikace nefungovala. Podle network policy byl na celém subnetu stavový FW, a příchozí spojení bylo filtrováno.

Je zatraceně velký rozdíl mezi tím, zda je jen věcí vaší volby, jaké komunikační kanály, odkud a kam povolíte, nebo zda tomu brání obezlička, ke které jste donucen nedostatkem adres, a na vybranou nemáte.

NAT řeší reálný problém (nedostatek adres)

Maškaráda (protože tu máte na mysli, ne NAT obecně) problém nedostatečné velikosti adresního prostoru IPv4. Naopak, dalo by se říct, že bujení maškarád řešení tohoto problému naopak oddálilo.

protože nastal mnohem dříve, než se nedostatek adres vůbec začal projevovat.

Určitě? Na podzim 1992, kdy jsem se poprvé setkal s Internetem, už se o tomto problému vědělo a už tehdy dávala extrapolace dosavadního vývoje odhad, že nezmění-li se něco, adresy do dvou let dojdou. Přesto ještě o pět let později byla naše katedrální tiskárna dostupná z celého světa…

[Michal Kubeček]

Eh... správně samozřejmě mělo být "Maškaráda ... problém nedostatečné velikosti adresního prostoru IPv4 neřeší".

[pavlix]

ta vaše idea "přímé" komunikace nefungovala.

Já spíš mám z toho, co píšeš pocit, že fungovala dobře, jen byla omezená bezpečnostní politikou, kterou si firma sama schválila.

Povolení přístupu z venku na počítač je bezpečnostní riziko :), nicméně servery dostupné z internetu existují (a bezpečnost se u nich obvykle řeší jiným způsobem než odfiltrováním nebo vytažením kabelu).

NAT řeší reálný problém (nedostatek adres), výměnou za featuru, která byla už stejně dávno mrtvá.

No comment.

[pavlix]

BTW nezapomínej na to, že NAT, jako bonus, představuje pro vnitřní klienty docela solidní bezpečnostní vrstvu a věř tomu že i z tohoto důvodu se NAT zanedlouho začne objevovat i v IPv6 sítích.

Ta bezpečností vrstva se v prostředích, kde není NAT obvykle nazývá Firewall.

[pht]

NAT je připojení do internetu pro drtivou většinu domácích i firemních uživatelů.

Mate pravdu, ze pro "konzumni ucely" to "vetsinou staci". Je to ale velmi omezeny pohled. Kvuli nedostatku IP adres a NATu privatnich adres mame miliony siti ktere maji kazde tu samou adresu 10.x, mame miliony zbytecnych port redirectoru na routerech, mame slozite a packety prepisujici algoritmy pro podporu protokolu jako FTP.

Uz jste se nekdy setkal s problemem, ze Vas uzivatel se nemohl pres VPN pripojit na firemni mail, a to jen proto ze lokalni natovana sit mela stejny "privatni" rozsah jako Vase firemni? Uz jste si nekdy zkousel s kamaradem udelat VPN pripojeni a zjistil jste ze kamarad ma tu samou "privatni" IP adresu jako Vy?

Uz jste nekdy zkousel mit na natovane siti verejne dostupne sluzby? Je to pokazde o tom zavest nejaky uchylny port forwarding. Uchylne dualni konfigurace name serveru, NAT vyjimky pro lokalni uzivatele, a takto by se dalo pokracovat.

BTW nezapomínej na to, že NAT, jako bonus, představuje pro vnitřní klienty docela solidní bezpečnostní vrstvu a věř tomu že i z tohoto důvodu se NAT zanedlouho začne objevovat i v IPv6 sítích.

Nebudu tady naznacovat, ze NAT sam o sobe neochrani ani ň, ale zamysleme se nad tim co internet znamena pro bezna "konzumni" PC. Davame vsechny svoje PC s internet-nedospelym OS za NAT a nebo extra firewall, jelikoz na "zivem" internet pripojeni by neobstaly. Jak muzeme ocekavat rozsahlou adopci IPv6 s "zivymi" adresami kdyz uroven bezneho uzivatelskeho PC je 10 let pozadu za soucasnosti?

[alblaho]

Přesně, to se mi stalo, nemohl jsem používat firemní VPN, pač můj domácí router mi dával adresy ze stejného rozsahu. Tak jsem se tam musel složitě "tunelovat" prostřednictvím mého druhého počítače s veřejnou IP. Fuj!

NAT je zbytečná komplikace, ano mám tu pod stolem natovací router a cítím se bezpečněji, než kdybych měl veřejnou IP, kdybych měl IPv6, pořídil bych si firewall a byl bych chráněný _líp_. Ten router tu mám jenom proto, že od providera dostanu jenom jednu veřejnou adresu.

IPv6 je cesta kupředu, tvrdit, že NAT to všechno řeší je prostě blbost.

Vint Cerf ostatně tvrdí, že jedna z věcí, co by na IP změnil, je velikost adresního prostoru. Ale tehdy bylo 32 bitů až až, nelze mu to vyčítat.

Nat _není_ připojení do internetu, je to _nouzové_, _neplnohodnotné_ připojení do internetu.

[David Jaša]

Nebudu tady naznacovat, ze NAT sam o sobe neochrani ani ň, ale zamysleme se nad tim co internet znamena pro bezna "konzumni" PC. Davame vsechny svoje PC s internet-nedospelym OS za NAT a nebo extra firewall, jelikoz na "zivem" internet pripojeni by neobstaly. Jak muzeme ocekavat rozsahlou adopci IPv6 s "zivymi" adresami kdyz uroven bezneho uzivatelskeho PC je 10 let pozadu za soucasnosti?

V čem krabička s linuxem vevnitř a takovýmto nastavením iptables:

iptables -P FORWARD DROP
iptables -A FORWARD -i ${vnitrni_rozhrani} -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -a POSTROUTING -o ${venkovni_rozhrani} -j MASQUERADE

bezpečnější oproti krabičce s:

ip6tables -P FORWARD DROP
ip6tables -A FORWARD -i ${vnitrni_rozhrani} -j ACCEPT
ip6tables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

?

[Majklík]

Jenže ta IPv4 ukázka není jen NAT, je současně NAT i firewall, pokud z ní vyhodíte ty prví tři řádky, tak pak to bude jen NAT a IPv6 dále zmíněné řešení bude bezpečnější. Ve spoustě malých krabiček je současně aktivní NAT i firewall a v celé řadě není. Většina lidí je za těma krabičkama a v životě v nich nic nenastavovala a výchozí nastavení nebývá nejlepší.

Dále ta konfigurace firewallu pro IPv6 (jak ji máte uvedenou) vám zajistí, že budete pro značnou část IPv6 světa nedostupný, pokud bude takto konfigurovaný, aby vám fungoval korektně provoz pro IPv6, tak ta konfigurace musí být o dost složitější.

[pavlix]

dále zmíněné řešení bude bezpečnější.

IMHO nebude. Privacy extensions ti vyřeší počet strojů, mac adresy apod. Firewall ti vyřeší nevyžádané přístupy zvenku.

tak ta konfigurace musí být o dost složitější.

O dost složitější... to jako jedno zaškrtávací pole typu "povolit připojení k počítači zvenku" či "nechránit počítač firewallem"?

Co bys chtěl... do teď to zaškrtávací pole nebylo, protože to nešlo vůbec... nadávat na možnost povolit připojení k počítači zvenčí... to jsme se dočkali věcí.

I obyčejný "firewall" ve windows tuším ve výchozím nastavení přístup zakazuje, tak proč by stejné nastavení nemohlo platit i pro forward na domácích routerech?

[Majklík]

Pokud jsme si vědom, tak jsem snad psal, že mámli IPv4 síť jen za NATem, tak je to míň bezpečnější, než IPv6 síť za firewallem.

Co se týče toho firewallu u IPv6, tak rozhodně firewall, který bude fungovat tak, že dovnitř nepustí žádné nové spojení, ale jen co navazuje na existující bude mít ten efekt, že se pro vást nemalá část IPv6 světa stane nedostupnou. Bohužel v IPv6 se předpokládá pár věcí, které takto nastaveným firewallem zrušíte a máte smůlu (třeba jen blbým nepovolením ICMPv6 ECHO odříznete ty, kteří používají Teredo tunely, protože oni si prvně přes ping očmuchávají protistranu a pomocí echo reply dojde k sestavení dynamického tunelu). Podívejte se na pár RFC, které se zabývají doporučením, jak řešit ochlanu lokální sítě na IPv6. Třeba RFC 4890 řeší jen otázku ICMP protokolu, jeho součástí je i demo konfigurace, jak by takový firewall pomocí iptables měl ideálně vypadat, aby to chránilo vnitřní síť a zároveň udrželo IPv6 v maximální možné míře funkční. Ten výpis je na 7 stránek, a to je trošku dost víc, než ty tři řádky uvedené o pár příspěvků výše.

[pavlix]

Pokud jsme si vědom, tak jsem snad psal, že mámli IPv4 síť jen za NATem, tak je to míň bezpečnější, než IPv6 síť za firewallem.

Tak toho jsem si úplně vědom nebyl.

Podívejte se na pár RFC, které se zabývají doporučením, jak řešit ochlanu lokální sítě na IPv6.

Určitě to ještě projdu :).

Ten výpis je na 7 stránek, a to je trošku dost víc, než ty tři řádky uvedené o pár příspěvků výše.

Dobrý firewall byl vždycky trošku delší než tři řádky. Zakázat vše zvenčí není horší než NAT, o to mi šlo, detaily nastavení firewallu, aby fungovaly věci, které IPv6 přináší navíc, to už je jiná věc. IPv6 věci komplikuje pouze tím, že umožňuje pracovat bez NAT. Kvůli bezpečnosti se dá velmi jednoduchý firewall, který má ale vedlejší efekt, že pohřbí výhody, které jsme získali.

Novou věcí je to, že ten vedlejší efekt pro konkrétní chtěné přístupy zvenčí chceme napravit. Nebo ne?

[Majklík]

Jo, to pak beru s trochou přivřeného zraku. Asi by mohlo platit, že NAT na IPv4 může způsobovat podobné potíže, jako takto restriktivní firewall. Stejně je to diskuse spíše akademická. V korporátním prostředí stejně nebude obvkyle přímé spojení mezi LAN a WAN stranou, všechno půjde přes nějakou proxinu, která bude filtrovat a vyžadovat ověřování. Aspoň ve větších firmách tomu tak je. Ono když člověk v praxi už musel řešit takové vtípky, jako trojan, který simuloval IMAP provoz a uspěšně takto vynesl celou DB firmy a asi tři různe IDSka ani nepípla, případně jiný, který simulovat SIP VoIP a úspěšně zajišťoval odposlech firmy přes mikrofony v notebookách, tak si pak firmy rozmyslí nějaký volný přístup na síť pro cokoliv. Čili budem řešit spíše menší firmy, které ještě nenarazily a SOHO segment.

[David Jaša]

Dále ta konfigurace firewallu pro IPv6 (jak ji máte uvedenou) vám zajistí, že budete pro značnou část IPv6 světa nedostupný, pokud bude takto konfigurovaný, aby vám fungoval korektně provoz pro IPv6, tak ta konfigurace musí být o dost složitější.

Coby člověku provozujícímu VoIP zařízení je mi to docela jasné. Účelem ale bylo ukázat nesmyslnost tvrzení o vylepšování bezpečnosti pomocí NATů.

[Petr Slansky]

Diky za NAT a maskarady! Dovedete si predstavit tu hruzu, kdyby kazdy koncovy pocitac byl pristupny z interentu? To by byl raj viru, trojskych konu i ostatni haveti. Tech bezpecnostnich problemu....

Osobne v IPv6 moc neverim, kdyby bylo potreba, uz by bylo nasazeno. Zatim je to jen experiment a u toho asi i zustane (viz prispevek vyse, ze jej ani v roce 2008 univerzity neuzivaji; university nemaji vlastne ani moc motivaci, vetsinou maji vlastni IPv4 rozsah...).

[trekker.dk]

To by byl raj viru, trojskych konu i ostatni haveti. Tech bezpecnostnich problemu...

Bezpečnostní problémy lze řešit jinak, než schováváním se. A pokud někdo provozuje k zavirování náchylnou parodii na OS, je to jeho problém a nevidím důvod, proč kvůli tomu omezovat nás ostatní.

[hankey]

+1

[tezkatlipoka]

A pokud někdo provozuje k zavirování náchylnou parodii na OS, je to jeho problém a nevidím důvod, proč kvůli tomu omezovat nás ostatní

Na to nemuzu rict nez BLA BLA BLA BLA

[David Jaša]

To znamená co, že kvůli průstřelnosti windows mají mít všichni Internet zkriplený? I ti, kteří si třeba pořídí SIP telefon a nějakou krabičku s firewallem?

[Michal Kubeček]

Nemůžete-li říci nic jiného než tohle, je obvykle lepší neříkat nic…

[pavlix]

+1

[Petr Slansky]

Bezpečnostní problémy lze řešit jinak, než schováváním se.

Jiste. Ale i schovavani je docela ucinou metodou. Stejne tak lze mozna nedostatek IPv4 adres resit jinak, nez prechodem na IPv6. Uvidime jak se to vyvine; o IPv6 se se mluvi uz dlouho a stale se prakticky nic nedeje; nedostatek IPv4 adres muze podporit vznik novych technologii/reseni, ktere jeste vice eliminuji nutnost IPv6 (treba rozdeleni internetu na nekolik separatnich oblasti, China se treba uz dnes pekne izoluje a ja na jejich servery taky vlastne moc nechodim)

A pokud někdo provozuje k zavirování náchylnou parodii na OS, je to jeho problém a nevidím důvod, proč kvůli tomu omezovat nás ostatní.

1) spocitejte si, kolik jste za posledni mesic stahl pro svuj Linux bezpecnostnich updatu 2) ne kazdy stahuje bezpecnostni updaty (palti pro Linux i Win) 3) napadeny pocitac zatezuje sve okoli (muze posilat spam, generovat utocne pakety, atd) 4) postizeny vubec nemusi vedet, ze jeho PC je zdrojem problemu, takze to neresi. 5) skutecne si myslite, ze vase lednicka a varna konvice musi byt dostupne z internetu? Verite ze OS ve vasi lednice a varne konvici bude dostatecne zabezpecen a bude se pravidelne updatovat?

Je vlaste i ve vasem zajmu, aby bylo nakazenych pocitacu co nejmene, nema to s OS moc spolecneho, protoze jediny pocitac ktery je 100% bezpecny je jen ten, ktery neni pripojen do site... Muzete rikat "parodie na OS", ale ve vetsine pripadu nemate zatim rozumnou alternativu (vetsina uzivatelu si porizuje nejlepsi dostupne reseni, ktere si mohou dovolit, kdyby si mysleli ze Linux je nejlepsi, meli by jej; k cemu nejlepsi OS, kdyz k nemu nejsou aplikace??

[xm]

nedostatek IPv4 adres muze podporit vznik novych technologii/reseni, ktere jeste vice eliminuji nutnost IPv6 (treba rozdeleni internetu na nekolik separatnich oblasti, China se treba uz dnes pekne izoluje a ja na jejich servery taky vlastne moc nechodim)

To si snad děláte jen blbou srandu??? Lidem s tak stupidními názory bych nejraději přístup na Internet zakázal (dřív než bude pozdě a než ho zničí) :-P Ale naštěstí takových exotů jako jste vy je mezi technicky vzdělanými lidmi naprosté minimum, to mě hřeje u srdce

[trekker.dk]

nedostatek IPv4 adres muze podporit vznik novych technologii/reseni, ktere jeste vice eliminuji nutnost IPv6 (treba rozdeleni internetu na nekolik separatnich oblasti, China se treba uz dnes pekne izoluje a ja na jejich servery taky vlastne moc nechodim)

Budu dělat, že tohle jsem nečetl, protože jinak bych musel použít slova jako blbec a podobná...

1) spocitejte si, kolik jste za posledni mesic stahl pro svuj Linux bezpecnostnich updatu

Všechny, které byly v distribuci. Tzn. minimálně opravu toho lokálního získání roota.

2) ne kazdy stahuje bezpecnostni updaty (palti pro Linux i Win)

To je jeho blbost. A kvůli blbosti jiných se přece já nenechám omezovat.

3) napadeny pocitac zatezuje sve okoli (muze posilat spam, generovat utocne pakety, atd)

Od toho je tu ISP, aby takové PC odstřihl od sítě a řekl majiteli, ať si to nechá spravit.

4) postizeny vubec nemusi vedet, ze jeho PC je zdrojem problemu, takze to neresi.

Viz předchozí mojí větu.

5) skutecne si myslite, ze vase lednicka a varna konvice musi byt dostupne z internetu? Verite ze OS ve vasi lednice a varne konvici bude dostatecne zabezpecen a bude se pravidelne updatovat?

Mě by stačil počítač.

[pavlix]

Stejne tak lze mozna nedostatek IPv4 adres resit jinak, nez prechodem na IPv6.

Jistě, třeba IPv9 žejo :D.

Uvidime jak se to vyvine; o IPv6 se se mluvi uz dlouho a stale se prakticky nic nedeje;

Jen dění okolo IPv6 možná dostatečně nesleduješ.

treba rozdeleni internetu na nekolik separatnich oblasti

Internet je od slova internetworking, neboli propojování sítí, ne jejich rozdělování.

Muzete rikat "parodie na OS"

Offtopic (už od toho, na koho reaguješ), no comment.

[trekker.dk]

Offtopic (už od toho, na koho reaguješ), no comment.

OS, který na počítači běží, je offtopic vzhledem k To by byl raj viru, trojskych konu i ostatni haveti. Tech bezpecnostnich problemu.... ??? Zdá se, že politická korektnost začíná pronikat i do IT.

[Käyttäjä 11133]

Ano je offtopic. Ono to je totiž o tom jak si ti lidé nastaví firewall. A to, že by lidi museli na Windows mít antivir není pravda. Nejlepší antivir je mozek.

[trekker.dk]

Tak ještě jinak - kolik virů, trojanů a ostatní havěti znáš pro ostatní OS? Pokud vím, tak jich moc není, takže nějaká souvilost s OS tady zjevně je.

Ano, dalším faktorem je, jestli lidi spustí tu přílohu po_kliknuti_sem_obdrzite_4GB_porna_zdarma.exe, ale to nijak nedokazuje, že na OS nezáleží. Jak bylo již dvakrát řečeno, tenhle útok závisí na tom, jestli se uživatel napadne sám a na veřejné/neveřejné IP nezáleží.

Kde na přístupnosti z internetu záleží, to jsou vzdálené útoky bez asistence uživatele na místě. A v takovém případě má volba OS vliv naprosto jednoznačně.

[pavlix]

Nějaká souvislost tady zřejmě je :). Ale zbytek toho, co píšeš o windows jsou jenom tvoje osobní dojmy :). Někde se trefuješ do reality, někde ne. Ale vypovídací hodnota v tomhle případně nula.

[trekker.dk]

Někde se trefuješ do reality, někde ne.

Bez konkrétního ukázání, kde se netrefuju do reality a kde jo, je vypovídací hodnota tvého příspěvku nula.

[Michal Kubeček]

1) spocitejte si, kolik jste za posledni mesic stahl pro svuj Linux bezpecnostnich updatu 2) ne kazdy stahuje bezpecnostni updaty (palti pro Linux i Win) 3) napadeny pocitac zatezuje sve okoli (muze posilat spam, generovat utocne pakety, atd) 4) postizeny vubec nemusi vedet, ze jeho PC je zdrojem problemu, takze to neresi.

A v čem konkrétně podle vás v tomto ohledu pomůže další oddalování přechodu na IPv6? Uvědomte si, že dnes je jen velmi malá část počítačů, o nichž tady mluvíte, napadena klasickým útokem zvenčí. Mnohem častější je to, že si uživatel pustí do počítače škodlivý kód sám (ať už pomocí webového prohlížeče nebo mailového klienta).

[Petr Slansky]

Chapu to tak, ze nejvetsi motivaci pro IPv6 je aby kazdy pocitac mohl byt dostupny na internetu. Nekteri rikaji, ze IPv4 adresy jiz dosly, podle jinych se tak melo stat nejpozdeji v roce 2010. Pote co byly uvolneny nejake IPv4 site, je mozno s IPv4 dozit do 2012. Jsou tato fakta spravna?

Silni hraci sve IPv4 rozsahy maji, nedostatek IP address trapi prezne jen nove subjekty (novacky); vlastne neni moc v zajmu silnych rozdavat adresy prichozi konkurenci, treba je budou moci v budoucnu prodavat anebo drazit, jen je treba nejprve vyvolat paniku, ze IPv4 adresy jiz dosly. Domacim uzivatelum staci ve vetsine pripadu jen pristup pres NAT (vyjimkou jsou "piratske" p2p a domaci servery, mozna i VoIP). University dnes nejsou ve stejne situaci jako pred lety, kdy vznikal IPv4; zacinalo se na zelene louce, a bylo treba site nejak propojit, bezpecnostni problemy jake zname dnes exitovali jen na papire a ve sci-fi, site pouzivali jen profesionalove.

Je rok 2008, jeste nedavno to vypadalo ze v roce 2010 dojdou IP adresy a nic viditelneho se nedelo, dva roky pred "koncem sveta" mame jen nekolik testovacich siti s IPv6. Z meho pohledu je prechod od IPv4 na IPv6 docela slozita zalezitost a prechod nejakou dobu potrva a vubec nebude levny (kdo zaplati vymenu hw??) a bude treba vyresit hromadu problemy s kompatibilitou; srovnejete s tim, co se delo kvuli "Y2k", coz bylo vyzrazne jednodussi proti prechodu na IPv6. Toto jsou skutecnosti, proc si myslim, ze IPv6 muze skoncit ve slepe ulicce jako se to stalo i jinym skvelym technolgiim (OSI sitovy model, ATM, HD DVD,...).

BTW, moc toho o IPv6 nevim, ale zaznamenal jsem ze uz se o nem dlouho mluvi a porad nic; uz jsem podobnych nafouklych bublin nekolik zazil.. . Pokud se IPv6 nakonec prosadi, bude to mnohem pozdeji, dnes si dnes myslime... Nebo ze by zmenu prineslo uvolneni nekolika zhavych filmu na IPv6 zadarmo? To by byla dost pikantni historie prosazeni IPv6...

[Kroko]

Dle mého se mluví málo, hodně lidí v oboru o tom pořádně skoro nic neví. Na různých kurzech apod. pro správce sítě se pořád ještě učí IPv4 (nebudu jmenovat tu moderní firmu která tyhle kurzy pořádá a nechává si je solidně zaplatit). Ano mluví se málo a taky to nikdo neřeší. Já to vidím tak, že se za nějaký čas firmy proberou "ze spánku" a to se pak budou řešit problémy ve zmatku a ne klidný přechod.

[pavlix]

Jo.... zmatkovitý přechod asi bude.

[Michal Kubeček]

Silni hraci sve IPv4 rozsahy maji, nedostatek IP address trapi prezne jen nove subjekty

Nedostatek adres trápí i ty "zavedené" (jen si to někteří neuvědomují). Nebo snad myslíte, že když někdo se skřípěním zubů funguje nad IPv4 s maškarádami, znamená to automaticky, že IPv6 nepotřebuje nebo nechce?

Domacim uzivatelum staci ve vetsine pripadu jen pristup pres NAT (vyjimkou jsou "piratske" p2p a domaci servery, mozna i VoIP).

No vidíte, že i vy sám víte o službách, které s vaším oblíbeným dělením na klienty a servery nevystačí.

proc si myslim, ze IPv6 muze skoncit ve slepe ulicce jako se to stalo i jinym skvelym technolgiim (OSI sitovy model

Mohl byste tu myšlenku s OSI modelem blíže upřesnit?

BTW, moc toho o IPv6 nevim

Všiml jsem si…

[Filip Jirsák]

Chapu to tak, ze nejvetsi motivaci pro IPv6 je aby kazdy pocitac mohl byt dostupny na internetu. Nekteri rikaji, ze IPv4 adresy jiz dosly, podle jinych se tak melo stat nejpozdeji v roce 2010. Pote co byly uvolneny nejake IPv4 site, je mozno s IPv4 dozit do 2012. Jsou tato fakta spravna?

Z toho, že dnes každý protokol musí řešit, jak se dostat přes NAT (a tedy z toho, že NAT dnes není nějaká podivná výjimka, ale věc, se kterou se musí počítat), lze snadno dovodit, že IPv4 adresy už (dávno) došly.

[pavlix]

Že by téma, kde se shodnem? :D Jaká to podivná náhoda?

[Majkls]

nedostatek IPv4 adres muze podporit vznik novych technologii/reseni
Ano, nedostatek ipv4 a používání natu učí dělat takové kriploidní věci, jako je třeba skype. Jak by bylo super, kdyby nebylo třeba supernodů a nechalo se to propojovat přímo. Nebo můžu dále jmenovat ICQ, jabber, SIP, FTP .... určitě bych mohl pokračovat. Ano všechny tyto protokoly buď mají s natem problém, nebo ho musí obskurdně obcházet. Takže pokud něco IPv4+nat dělá, tak je to podle mého názoru prodražování výroby software. kolik asi musíte dopsat kódu, abyste mohli obejít ipv4+nat a kolik by vás asi stálo dopsat podporu IPv6? Nehledě na to, o kolik musíte mít větší technologické zázemí (například provoz serverů). Vemte si, kolik by se ušetřilo výpočetního výkonu, kdyby servery ICQ nedělali nic jiného, než login+client routing (maximálně offline zprávy). To by byl luxus. 90% věcí by šlo posílat někde extra mimo servery.

[Michal Kubeček]

Přesně tak. Ten argument je asi tak přesvědčivý jako tvrdit, že monopol Českého Telecomu byl vlastně strašně skvělý, protože tím podpořili rozvoj bezdrátového připojení k Internetu.

Vemte si, kolik by se ušetřilo výpočetního výkonu, kdyby servery ICQ nedělali nic jiného, než login+client routing (maximálně offline zprávy). To by byl luxus. 90% věcí by šlo posílat někde extra mimo servery.

No jo, ale to přece nejde, to by se pak mnohem hůř odposlouchávalo… :-)

[pavlix]

Nojo... a víš kolik se na tom uživí lidí? :D

[Majkls]

tak by dělali něco jinýho... práce je dost, stačí se rozhlídnout .. ;)

[pavlix]

Diky za NAT a maskarady! Dovedete si predstavit tu hruzu, kdyby kazdy koncovy pocitac byl pristupny z interentu? To by byl raj viru, trojskych konu i ostatni haveti. Tech bezpecnostnich problemu....

Už se tu o existenci firewallu psalo.

Osobne v IPv6 moc neverim, kdyby bylo potreba, uz by bylo nasazeno. Zatim je to jen experiment a u toho asi i zustane (viz prispevek vyse, ze jej ani v roce 2008 univerzity neuzivaji; university nemaji vlastne ani moc motivaci, vetsinou maji vlastni IPv4 rozsah...).

Univerzity motivaci k pokroku mají, jinak by nevzniklo ani IPv4.

IPv6 není jen experiment, je to upgrade staršího protokolu.

Otázky víry jsou jedna věc, jak se věci vyvinou věc druhá, já věřím, že IPv4 je z důvodu nedostatku adres dlouhodobě neudržitelné. Ostatní věci beru jako příjemný bonus.

[Michal Kubeček]

Za prvé: to, že má stroj neveřejnou adresu, ještě nutně neznamená, že na něj nelze navázat spojení zvenku. Za druhé: naopak, to, že má veřejnou adresu, ještě neznamená, že na něj spojení navázat lze. Za třetí: drtivá většina virů a trojských koní navázat spojení nepotřebuje, protože využívá toho, že hloupý uživatel si je ochotně stáhne sám a postará se, aby mu mohly do počítače.

[Filip Jirsák]

Diky za NAT a maskarady! Dovedete si predstavit tu hruzu, kdyby kazdy koncovy pocitac byl pristupny z interentu?

Tomu ale NAT nijak principiálně nebrání. Je to jenom vedlejší účinek některých implementací NATů, a jakožto vedlejší účinek to samozřejmě není testováno, zda tou skutečně brání, či nebrání (ostatně různé tunely skrze NAT jsou důkazem toho, že nebrání, jen komplikuje). Ostatně NAT může být klidně udělán tak, že každý koncový počítač za ním bude z internetu dostupný…

[Petr Slansky]

Jiste, NAT nezabrani uzivateli, aby otevrel svuj pocitac svetu tim, ze si na nem spusti SW, ktery vytvori tunel. Ale ochrani treba pocitace, ktere maji nainstalovane sluzby s "default" hesly (treba testovaci stroje ve firme), pripadne jednoussi HW (treba lednicka s internetovym pripojenim), ktery nemusi mit implementaci TCP/IP podle vsech bezpecnostnich standartu.

[Kroko]

Myslím, že pokud už někdo bude mít takovou ledničku, tak pro něj nebude problém si pořídit bránu, pokud ji tedy bude chtít připojit do sítě. A pokud má někdo ve firmě testovací servery s default hesly a nemá vyřešenou bezpečnostní politku tak je upřímně řečeno vůl kterému nepomůže ani NAT ani svěcená voda ...

[Michal Kubeček]

Ne, neochrání. Ještě jednou: maškaráda nezabrání přístupu do vnitřní sítě, tomu brání filtr, který se obvykle aplikuje společně s tou maškarádou. Jenže ten filtr mu brání i bez maškarády, takže je nesmysl tvrdit, že má maškaráda nějaký pozitivní bezpečnostní efekt.

[Filip Jirsák]

Ne, neochrání. NAT, který mapuje adresy 1:1 je také NAT. NAT, který namapuje x portů z jedné IP adresy na x různých kombinací IP adresa : port z vnitřní sítě je také NAT. NAT, který bude všechny porty z jedné IP adresy směrovat na odpovídající porty počítače ve vnitřní síti po dobu jedné hodiny, a po hodině se přepne na další počítač atd., je také NAT. A tak dále. To, o čem píšete vy, k tomu (mimo jiné) slouží firewall.

[pavlix]

Ale ochrani treba pocitace, ...

Slyšel jsi někdy o firewallu?

[Michal Kubeček]

Nestačí. Jakmile budete mít uživatele, kteří nevystačí s představou, že Internet = web + mail, stačit vám to přestane.

[pavlix]

A... přehlédl jsem, díky :).

[Heron]

Firewall tu není od toho, aby cokoliv kam přeposílal. A portů je dost tak akorát pro jeden počítač.

Máme to ve firmě, jedna adres ven a podle portu se pak dostanu ne určenej počítač.

Takže se připojuješ na jednu IP, jen na různé porty. Nebylo by praktičtější se připojovat na konkrétní adresy (těch různých strojů) a standardní port dané služby?

[Jirka]

Podle té zprávičky se to odsouvá o 2 roky. To mi přidalo klid na duši.

BTW: Těch 67 milionů vrácených IP adres mi z pohledu IPv6 připadá jako plivnout do oceánu.

[Jirka]

To s tím "klidem na duši" bylo míněno jako sarkazmus. Možná to tak nevyznělo, tak to pro jistotu dodávám.

[the.max]

neboj, my to pochopili (tedy alespon dpoufam ze prinejmensim vetsina z nas

[Michal Kubeček]

Proč mluvíte o strašení? Jako strašení mi připadají spíš zprávy o hledání dalších a dalších záminek pro odkládání (nebo spíš zpomalování) přechodu. Podobnost s přechodem na digitální televizní vysílání v ČR je docela alarmující.

[pavlix]

IP adres není dost, nechtěj mi domu dát víc než jednu. Kdyby jich bylo dost, dostal bych celý rozsah.

[Stan.]

už před cca 4-5 lety tuším jsem měl doma subnet IPv6 (tunelovanou) přes p. Ludviga (http://www.logix.cz). Pak přišla práce a nebyl čas si s tím hrát. Zkoušel jsem u sixxs.net žádat, ale měli problémy s verifikací mého mailu. Mají tam docela velké restrikce. A když jsem jim to vyšvětloval tak vůbec nereagovali :(

tak doufám že se v pokračování dočkám info co a jak :)

ono nativní podpora IPv6 v koncových zařízeních, které používají provideři zatím moc není. A když ta možnost je tak to stojí nemalé peníze (má na mysli cisco). A provideři ani nenabízejí (až na pár) možnost IPv6 konektivity.

[Floyd]

No, já nevím jak ISP, ale velcí hráči na trhu mají IPV6 - jinak by ho asi ani nepeerovali v nixu: http://nix.cz/cz/peering_ipv6

[Stan.]

no právě, ale bez podpory ISP to nepůjde čistě :( zrovna sem si psal teď s GTS Novera a IPv6 nenabízejí.

[Dan Ohnesorg]

To nesmite chodit do GTS, to je dinosaurus. Musite za temi mensimi, kde jeste maji radost z prace a dostatek nadseni. Realne IPv6 dava Volny, UPC, samozrejme CESNET, ale to neni provider, myslim ze by se o tom dalo mluvit i z lidmi ze Sloane. Jediny problem je, ze na IPv6 nejde uzavrit SLA ale ke konektivite se dostat da.

Jak uz tady nekdo rikal, tak protoze u IOSu si musite vybrat jestli IPv6 nebo nektere jine funkce, tak se to ale stejne musi pres nektere spoje hnat skrz tunely, ale to zvenku nepoznate.

[Käyttäjä 11133]

SLA?

[Dan Ohnesorg]

Garantovanou dostupnost

[Jirka]

Service Level Agreement - dohoda o poskytovaných službách.

[Stan.]

to se lehko řekne jít k někomu jinému :) doma (na venkově)jste limitován cenou a dostupností. Ale tam to budu řešit tunelem jako dříve.

Máte nějaké konkrétní zkušenosti s UPC a nativní podporou IPv6? Obecně je s UPC strašná řeč. Dokud vás lákají tak slibují a slibují. A když podepíšete tak čekáte, čekáte :)

Díky

[Dan Ohnesorg]

UPC postupne konvertuje k molochu, ktery se zhrouti vlastni vahou.

Nevim jestli se IPv6 nekdy realne dostalo k zakaznikum mimo serverovu UPC. Tam ale fungovalo. On mozna bude problem s temi modemy, ktere lidem rozdavaji.

[pavlix]

Nevím, jak to má přesně UPC, ale modemy by obecně neměly IP vůbec potřebovat.

[pavlix]

Jo, nastavení mailu je problém... správné dns záznamy apod. Nativní podpora v koncových zařízejích je, Mikrotik mě stál cca 1100 bez daně samotná deska (ještě zbývá krabička a napájení, ale tam záleží jak si to člověk udělá....). Asusy tuším uměj v pohodě taky.

Windows, Linux a BSD v pohodě.

[Michal Kubeček]

Bohužel většina velkých firem apriorně odmítá cokoli, na čem není napsáno Cisco, případně ještě Juniper. To umožňuje (nejen) těmto firmám efektivně brzdit přechod na IPv6 a vydělávat na prodeji nástrojů pro něco, co by na IPv6 nebylo vůbec potřeba.

[pavlix]

Co jsem stihl pochytit, tak Cisco s IPv6 funguje dobře, jen nevím odkdy.

[Stan.]

ano funguje, ale není v zakladním IOSu, ale až v tom skoro nejvyšším (Advanced IP services) a ten něco stojí :( a platit jen kvůli IPv6 a ostatní funkce z toho vyššího iosu nepotřebovat je docela luxus pro firmu, když to "není" potřeba. Bavil jsem se o tom i s lidma od cisco (obchodníci i technici) a zatím se na lepší casy vůbec neblýská :( Budu se ptát zase na cisco-expo :) třeba se něco změnilo.

[pavlix]

Áha, díky za info.

[Majkls]

a co juniper? Ten by nestačil? :)

[Michal Kubeček]

Což o to, funguje, to ano. Ale AFAIK to znamená koupit novou škatuli a navíc dražší.

[Jirka]

Příloha:

• Simpsons_cisco.jpg (151497 bytů)

Cokoliv, na čem je napsáno Cisco? Třeba všc co je na obrázku v příloze?

[Käyttäjä 11133]

To že firma odmítá cokoli na čem není Cisco neznamená, že přijme cokoli na čem slovo Cisco je...

[Michal Kubeček]

Psal jsem "odmítá cokoli, na čem není napsáno Cisco"... :-)

[Jirka]

Hm, ono to na věci moc nemění.

[Stan.]

nastavené by to bylo i dobře, ale odmítají e-mail adresy z freemailů jako seznam.cz atd..

[pavlix]

Asi věděj proč.

[Petr Slansky]

Lze koupit SOHO router (mala krabicka, D-Link, Linksys,...) s podporou IPv6, pripadne i s podporou tunelovani IPv6 pres IPv4? Obavam se ze zatim toto je pole ignorovane a neorane; nikdo to prakticky nepotrebuje

[pavlix]

Určitě to jde, já jsem tuším viděl podporu někde u Asusu. Nevím, jestli i tunelování. Já používám Mikrotik RouterOS, který je ale spíš cílený na zkušenější uživatele :D. V příštím díle bude i něco málo z příkladů nastavení.

A... pokud má člověk čas a nervy, může na to vždycky nahrát některý z opensource OS. Tam bývá podpora IPv6 bezproblémová.

[Käyttäjä 11133]

Pro Asusy je Olegův firmware, který umí tunely z webrozhraní... Dále pak je možnost na ně hodit openWRT a všechno si nastavit pěkně ručně přes ip.

[Grunt]

Já používám Mikrotik RouterOS, který je ale spíš cílený na zkušenější uživatele :D.

Prosím?

[pavlix]

Já používám Mikrotik RouterOS, který je ale spíš cílený na zkušenější uživatele :D.

Prosím?

O co prosíš?

[pavlix]

Samozřejmě oproti domácím routerům s dodávaným firmware, nesrovával jsem s OpenWRT, pokud ti jde o tohle.

Ale vzhledem k tomu, že se vyjadřuješ dost podivným způsobem, můžu jenom zkoušet hádat a číst myšlenky, třeba jsem se vůbec netrefil.

Příště zkus napsat i o co ti jde :).

[Grunt]

Samozřejmě oproti domácím routerům s dodávaným firmware, nesrovával jsem s OpenWRT, pokud ti jde o tohle.

Ale vzhledem k tomu, že se vyjadřuješ dost podivným způsobem, můžu jenom zkoušet hádat a číst myšlenky, třeba jsem se vůbec netrefil.

Příště zkus napsat i o co ti jde :).

Mně jde jen o to že RoS je spíše klikací frontend k Linuxovému jádru pro Windowsáky, který se snaží zjednodušovat než-li zařízení pro pokročilejší. Což je i jedna z příčin stavu síti s tahačema.

[pavlix]

Systému s příkazovým řádkem říkáš klikací frontend?

[Grunt]

Systému s příkazovým řádkem říkáš klikací frontend?

Máte na mysli tu parodii BASHe? Ale ne, zase tak moc hanit ho nemůžu a bohu dík alespoň za něj(Což už se u jiných věcí na RoS říct nedá). Není CLI jako CLI. A myslím si, že RoS se nekupuje kvůli hlavně tomu CLI.

[pavlix]

Parodii na BASH? Vždyť to s BASHem není téměř v ničem podobné.

Mě jejich příkazové rozhraní vyhovuje. Přešel jsem z Linuxového routeru... a je to značně pohodlnější. Prostě ten systém dělá to, co chci.

Jsem si vědom toho, že není tak flexibilní jako ručně poskládané řešení na bázi Linuxu nebo BSD, ale na hraní tu mam jiný mašiny.

Jinak to grafický nastavovátko umí přesně to samé, co se nastavuje příkazama. Holt místo příkazu na přidání do tabulky máš tlačítko na přidání do tabulky... místo atributů máš nastavovací políčka. Ale ve skutečnosti jediné, co nabízí navíc jsou grafy, které jinak se do textu blbě kreslí.

Doporučuju používat nebo nepoužívat, ale neurážet, podle mě je to moc hezká práce, jak hardware, tak software.

[Grunt]

Parodii na BASH? Vždyť to s BASHem není téměř v ničem podobné.

Právě, kdyby tam dali BASH udělali by 1000x lépe(Ani tak né z pohledu ovládání spíše jako z pohledu skriptování).

Mě jejich příkazové rozhraní vyhovuje.

Mně až na malé drobnosti také, bohužel oficiálně nedovoluje všechny vymoženosti z GNU systémů, což mě nehorázně štve.

Jsem si vědom toho, že není tak flexibilní jako ručně poskládané řešení na bázi Linuxu nebo BSD, ale na hraní tu mam jiný mašiny.

Oficiálně není tak flexibilní, trošku větší otevřenost by jim určitě neuškodila.

Ale ve skutečnosti jediné, co nabízí navíc jsou grafy, které jinak se do textu blbě kreslí.

O čem je řeč?

Doporučuju používat nebo nepoužívat, ale neurážet, podle mě je to moc hezká práce,

Z různých distribucí a OS bych si dovolil tvrdit, že i jedna z nejpovedenějších , ale nenabízí vše.

jak hardware

Myslíte RouterBoardy?

[pavlix]

Parodii na BASH? Vždyť to s BASHem není téměř v ničem podobné.

Právě, kdyby tam dali BASH udělali by 1000x lépe(Ani tak né z pohledu ovládání spíše jako z pohledu skriptování).

Jak už jsem řekl, vyhovuje mi.

Mě jejich příkazové rozhraní vyhovuje.

Mně až na malé drobnosti také, bohužel oficiálně nedovoluje všechny vymoženosti z GNU systémů, což mě nehorázně štve.

Já jsem s tím smířený, jak už jsem řekl, na hraní mám jiné stroje.

Jsem si vědom toho, že není tak flexibilní jako ručně poskládané řešení na bázi Linuxu nebo BSD, ale na hraní tu mam jiný mašiny.

Oficiálně není tak flexibilní, trošku větší otevřenost by jim určitě neuškodila.

Možná.

Ale ve skutečnosti jediné, co nabízí navíc jsou grafy, které jinak se do textu blbě kreslí.

O čem je řeč?

Traffic, převážně.

Doporučuju používat nebo nepoužívat, ale neurážet, podle mě je to moc hezká práce,

Z různých distribucí a OS bych si dovolil tvrdit, že i jedna z nejpovedenějších , ale nenabízí vše.

Zato nabízí to, co potřebuju, v trošku lépe (pro mě) použitelné podobě. Šetří mi čas, ve kterém si pak můžu hrát s jinými věcmi.

jak hardware

Myslíte RouterBoardy?

Jj, co jiného.

[Michal Kubeček]

Právě, kdyby tam dali BASH udělali by 1000x lépe(Ani tak né z pohledu ovládání spíše jako z pohledu skriptování).

Řekl bych, že důvod, proč tam není bash, je obsažen v první větě sekce Bugs manuálové stránky:

It's too big and too slow.

[Ondrej 'SanTiago' Zajicek]

No, oni zas tak omezeny mistem nejsou. Ten jejich hw ma bezne 64 MB flash, tam se toho vejde... Krom toho existuje mnoho jinych, praktickych a dobre pouzitelnych bourne shell kompatibilnich shellu.

[Grunt]

Řekl bych, že důvod, proč tam není bash, je obsažen v první větě sekce Bugs manuálové stránky:

It's too big and too slow.

Ale no ták:

lrwxrwxrwx 1 root root       7 2008-02-22 13:21 [ -> busybox
lrwxrwxrwx 1 root root       7 2008-02-22 13:21 ash -> busybox
-rwxr-xr-x 1 root root    3232 2008-01-25 09:41 ask
lrwxrwxrwx 1 root root       7 2008-02-22 13:21 basename -> busybox
lrwxrwxrwx 1 root root       3 2008-02-22 13:21 bash -> ash
-rwxr-xr-x 1 root root     421 2008-01-24 15:37 bash_login
-rwxr-xr-x 1 root root     540 2008-02-15 09:43 burnK6
-rwxr-xr-x 1 root root     604 2008-02-15 09:43 burnK7
-rwxr-xr-x 1 root root     532 2008-02-15 09:43 burnP5
-rwxr-xr-x 1 root root     540 2008-02-15 09:43 burnP6
-rwxr-xr-x 1 root root  154516 2008-02-15 09:42 busybox
lrwxrwxrwx 1 root root       7 2008-02-22 13:21 cat -> busybox
-rwxr-xr-x 1 root root    8092 2008-01-25 11:32 catlog
lrwxrwxrwx 1 root root       7 2008-02-22 13:21 cp -> busybox
lrwxrwxrwx 1 root root       7 2008-02-22 13:21 date -> busybox
lrwxrwxrwx 1 root root       7 2008-02-22 13:21 echo -> busybox
lrwxrwxrwx 1 root root       7 2008-02-22 13:21 expr -> busybox
lrwxrwxrwx 1 root root       7 2008-02-22 13:21 find -> busybox
lrwxrwxrwx 1 root root      15 2008-02-22 13:21 gosh -> /nova/bin/login
lrwxrwxrwx 1 root root       7 2008-02-22 13:21 hostname -> busybox
-rwxr-xr-x 1 root root  332903 2008-02-24 22:04 htop
lrwxrwxrwx 1 root root       7 2008-02-22 13:21 chmod -> busybox
lrwxrwxrwx 1 root root       7 2008-02-22 13:21 chown -> busybox
lrwxrwxrwx 1 root root       7 2008-02-22 13:21 ln -> busybox
lrwxrwxrwx 1 root root      15 2008-02-22 13:21 login -> /nova/bin/login
lrwxrwxrwx 1 root root      12 2008-02-24 22:08 ls -> /bin/busybox
lrwxrwxrwx 1 root root       7 2008-02-22 13:21 mkdir -> busybox
lrwxrwxrwx 1 root root       7 2008-02-22 13:21 mknod -> busybox
-rwxr-xr-x 1 root root      43 2008-01-24 15:37 mlogin
lrwxrwxrwx 1 root root       7 2008-02-22 13:21 mount -> busybox
lrwxrwxrwx 1 root root       7 2008-02-22 13:21 mv -> busybox
-rwxr-xr-x 1 root root    7084 2008-01-25 11:32 pacd
-rwxr-xr-x 1 root root    5508 2008-01-25 11:32 pakp
lrwxrwxrwx 1 root root       7 2008-02-22 13:21 rm -> busybox
lrwxrwxrwx 1 root root       4 2008-02-22 13:21 sh -> bash
lrwxrwxrwx 1 root root      17 2008-02-22 13:21 shell -> /nova/bin/console
-rwxr-xr-x 1 root root   72008 2008-02-15 09:42 telnet
lrwxrwxrwx 1 root root       7 2008-02-22 13:21 test -> busybox
lrwxrwxrwx 1 root root       7 2008-02-22 13:21 touch -> busybox
lrwxrwxrwx 1 root root       7 2008-02-22 13:21 umount -> busybox
lrwxrwxrwx 1 root root       7 2008-02-22 13:21 uname -> busybox
lrwxrwxrwx 1 root root       7 2008-02-22 13:21 usleep -> busybox

Myslel jsem to, tak že oficiálně z celého GNU Softu je tam tak jedině h…telnet.

[Petr Slansky]

Mikrotik krabicku (RB133) mam na stole, zrovna tu jsem nemyslel, neni to typicke SOHO zarizeni, spise stavebnice... Myslel jsem obycejny SOHO router za par korun. Pripadne nejakou Linux distribuci na router. IPcop? Asi ne. pfSense? Mozna. V kazdem pripade, IPv6 podpora je stale prilis slaba, neni potreba.

[Grunt]

Mikrotik krabicku (RB133) mam na stole, zrovna tu jsem nemyslel, neni to typicke SOHO zarizeni, spise stavebnice...

Všechno je to na jedno brdo. Nějaké ořezané embedded zařízení s Linoxovým jádrem(+ OSS nástrojema) a nějaký klikací frontend. Kdyby se chtělo tak jde narvat IPv6 všude, ale z lenosti nebo z ekonomického hlediska se to nedělá.

[Petr Slansky]

Teoreticky jde vse, podpora IPv6 je v Linuxu jiz dlouho. Ale proc si myslite, ze IPv6 je za dvermi, kdyz jej nikdo nepouziva?? Kdyz jsem si v roce cca 2005 napsal do TODO listu pripojeni pres 6in4 (ale nakonec zustalo jen u studie) a pak se o nej pokousel znovu behem vanoc 2007, tak jsme zjistil, ze se moc nezmenilo, jen UBYLO poskytovatelu "free" tunelu.

Mimochodem, dival jsem se na Mikrotik a nezda se mi, ze by umel IPv6, mozna jen na "bridge" interface. Verze RouterOS 2.9. Mozna ze IPv6 neni jen zdokumentovane, nebo to taktne zamlcuji aby nematli nezkuseneho ctenare; vse se toci jen kolem IPv4.

[pavlix]

Verzi 2.9 jsem nezkoušel, doporučuju upgrade.

[Grunt]

Mimochodem, dival jsem se na Mikrotik a nezda se mi, ze by umel IPv6, mozna jen na "bridge" interface. Verze RouterOS 2.9. Mozna ze IPv6 neni jen zdokumentovane, nebo to taktne zamlcuji aby nematli nezkuseneho ctenare; vse se toci jen kolem IPv4.

Od verze 3.0 má plnou podporu. A proto jsem také mluvil o ekonomickém hledisku.

[pavlix]

Tak já ho koupil s 2.9, ale neřešil jsem a upgradoval na 3.1, tuším, teď už snad 3.3.

[the.max]

...uz par dni 3.4

[pavlix]

Dost dní na to abych upgradoval, jak jsi mi říkal? :D

[Petr Slansky]

Verze 2.9 je dlouhodobe proverena, stabilni. Verze 3.0 je novinka. Nejvetsi potiz je ale s licenci, nejde snadno upgradovat z 2.9 na 3.0, viz licencni politika Mikrotiku; snad je verze 3.0 i narocnejsi na hw, ze? Domnivam se, ze vetsina techto krabicek nasazenych praxi ma jen verzi 2.x. :-|

[pavlix]

A vidíš, já upgradoval z 2.9 na 3.0 velmi snadno. Asi je to s tou licenční politikou trošku jinak.

Domnívám se, že 3.x není ve svém zastoupení bezvýznamná.

[the.max]

Za posledni 2 roky co jsem nakoupil mikrotiky, tak vsechny (L3 a L4) maji moznost upgrade na libovolnou verzi 3.x. Pokud mam L4 na 2.9.x a uograduju na 3.x, stale mam L4

[Grunt]

Verze 2.9 je dlouhodobe proverena, stabilni. Verze 3.0 je novinka. Nejvetsi potiz je ale s licenci, nejde snadno upgradovat z 2.9 na 3.0, viz licencni politika Mikrotiku;

Přesně to jsem měl na mysli tím ekonomickým hlediskem. Ono se trochu licenční politika změnila, ale kdyby chtěli rýžovat…

snad je verze 3.0 i narocnejsi na hw, ze?

To bude způsobeno přechodem z verze jádra 2.4 na 2.6 a možná také tím, že doposud tam nebyl CFS(I když tomu jak jádro pracuje s procesorem moc nerozumím, takže to spíše berte jak blábol). Většinu problémů s 100% vytížením CPU, ale způsobuje zacyklování některých procesů(Už si na ně chystám debugovací armádu).

[the.max]

Mikrotiku tu mam hafo a muzu rict, ze 2.9 opravdu 6ku neumi. 6ka je az od verze 3. Co mam zatim odzkouseno, ze se da pouzivat. umi to autokonfiguraci, staticky routovani (na dynamickem se pracuje (viz forum.mikrotik.com), je tam podpora 6to4, nejake tunelovani... 6ku mam jiz nasazenou, zatim tedy jen prez tunel, ale v utery (12.3.08) dostanu nativni 6ku...

[pavlix]

Kdo chce nastavovat třeba SixXS, tak se v příštím díle může těšit na příklady.

[satanatas]

The Great IPv6 Experiment

[xm]

To je dokonalý! Porno zdarma za IPv6 připojení Vzhledem k tomu, že porno vládne Internetu, mohlo by to mít úspěch

[satanatas]

jojo. minimálně pro jednu občerstvenoumyš tady se vyskytůjící.:)

[Michal Ludvig]

"the experiment is not yet active"

... hmm

[Käyttäjä 11133]

Jo, jo.. taky pořád čekám, IPv6 doma mám, ale experiment pořád nic

[Mortal]

prujem.cz je na ipv6 uz taky :)

[xm]

proc to? cekali jsme kdy to ipv6porn.com poradne roztoci a furt nic...

Pěkný

[Michal Vyskočil]

V současné době by pro popularizaci udělala víc nějaká p2p síť běžící pouze na ipv6. Pak by se muselo mezi lidi rozhodit povědomí, že je to rychlé a se super obsahem, spolu s tím, že na to potřebují ten lepší internet. To byste viděli ty fofry

[Käyttäjä 11133]

A chtělo by ji postavit na GNUnetu, nebo podobném onion-routingovém protokolu, aby byla zaručena i bezpečnost uživatelů. To by pak mohla být BFU killer app Ale zase si nejsem jistý tou rychlostí u onion-routingu

[Kvakor]

Kdyz se divam na obdobne prechazeni napr. u televize (analog->digital), tak se desim, jak bu nas bude probihat prechod na IPv6. Dokazete si predstavit, jak dloho to bude nasim providerum (tj. Kyslici a spol.) trvat? Pri jejich pristupu k broadbandu na to ani nechci myslet ...

Pro uzivatele to neni po softwarove strance zadny velky problem, vsechny bezne se na netu vyskytujici OS IPv6 podporuji a s postupujicim rozsirovanim bude pribyvat i podpora IPv6 u aplikaci pracujicich na nizsich sitovych vrstvach.

Vetsi sranda bude se spoustou zarizeni typu ADSL modemy, routery, HW firewally, WiFi AP podobne. V idealnim svete by vsechny tyhle potvurky IPv6 uz meli. V temer idealnim svete by vyrobci poskytli upgrade firmwaru, i za cenu napr. omezeni nekterych neprilis potrebnych featur (typu obrazek na pozadi ve webovem rozhrani).

Bohuzel v realnem svete se na to vetsina vyrobcu vykasle a lide si budou muset koupit potvurky nove (a urcite se najdou vykukove, co jim budou nutit i nove switche ). Dokonce je mozne, ze se bude prodavat nejaky udelator, ktery bude delat preklad protokolu a adres z IPv6 do IPv4 a zpet (NAPT-PT) a bojovnici proti NATu a vyznavaci "opravdovemu pripojeni k Internetu" budou zurit ...

[Käyttäjä 11133]

z IPv6 do IPv4 a zpet (NAPT-PT)

Tyhle tunelovací technologie přece už dávno jsou.

[petr_p]

A jsou již oficiálně pohřbené.

[pavlix]

Vetsi sranda bude se spoustou zarizeni typu ADSL modemy, routery, HW firewally, WiFi AP podobne. V idealnim svete by vsechny tyhle potvurky IPv6 uz meli.

Modemy IPv6 nepotřebují, lepší routery ho mají... co s těmi ostatními... no bude to zajímavé :). To bude nových instalací OpenWRT a podobných :D.

Poslední možnost je docela děsivá ale reálná :(.

[Jirka]

Je nutná podpora u WiFi AP? Podle mně fungují transparentně a jsou adresovatelné IP adresou jen kvůli jejich konfiguraci. Nebo se pletu?

[Käyttäjä 11133]

No to záleží kolik funkční toho AP chce člověk využívat. Pokud to chce jen jako AP tak není problém. Ale pokud chce člověk jejich DHCP server, tak je problém. Tedy WiFi AP v pohodě. WiFi "router" už nikoli.

[pavlix]

Může a nemusí. Pokud ho používáš jako bridge, tak podporu ipv6 nepotřebuješ.... to samé, když máš adsl modem, případně router, který přenastavíš, aby se choval jen jako eth. modem (můj umí... škoda že ho už k ničemu nepoužívám :)).

[Luboš Doležel (Doli)]

V idealnim svete by vsechny tyhle potvurky IPv6 uz meli. V temer idealnim svete by vyrobci poskytli upgrade firmwaru, i za cenu napr. omezeni nekterych neprilis potrebnych featur (typu obrazek na pozadi ve webovem rozhrani).

Abych pravdu řekl, nepřekvapilo by mě, kdyby na takové řešení začala tlačit unie. Když už nic jiného, představuje to zbytečnou ekologickou zátěž, protože hodně IPv4-only výrobků poletí oknem.

[pavlix]

Jasně... aby to nebylo jako s tou ropou a pákistánem (jen jsem slyšel nějaké fámy...).

[isaak]

Proč existuje pro IPv6 DHCPv6 server? Nemá IPv6 autokonfiguraci? A mohl by mi prosím někdo vysvětlit, jak po výměně síťové karty získám zpátky původní adresu, když IPv6 závisí na MAC adrese?

[Dan Ohnesorg]

Autokonfigurace ma problem v tom, ze poskytuje jen IP adresu a default GW. Pokud chcete predat dalsi veci, jako DNS servery, NTP, parametry pro bootovani, tak uz se bez DHCP serveru neobejdete.

IPv6 adresa se prihodi na rozhranni uplne stejne jako IPv4 adresa, takze kdyz vymenite kartu, nechate si puvodni IPv6 adresu, samozrejme pokud nehrozi, ze se karta nekdy objevi zase v obehu.

Autokonfigurace se pouziva u klientu, servery se nastavuji uplne normalne, treba www.debian.cz ma adresu 2001:718:1:4::2 a ta nema s MAC adresou nic spolecneho. To pouziti MAC je jen pomucka, jak udelat relativne bezpracne sit bez kolizi.

[pavlix]

DNS se tuším bude předávat přes autokonfiguraci, možná i něco dalšího. Spousta věcí se dá taky vyřešit nějakým anycastem/multicastem, na to, jak to bude v praxi vypadat se docela těším.

[pavlix]

Autokonfigurace jen oznamuje, je bezstavová.

IPv6 závisí na MAC adrese pouze při autokonfiguraci (bez privacy extensions), tzn... pokud chceš, aby závisela, kvůli jednodušší implementaci.

Můžeš používat ručně nastavené adresy nebo DHCPv6.

[Ondrej 'SanTiago' Zajicek]

Narozdil od mnoha zde komentujicich lidi si nemyslim, ze masivni nasazeni IPv6 skoncuje s NATem (ve forme source NAT, many to one). Potreba NATu je totiz zapricinena dvemi pricinami - nedostatkem IP adres a mechanismem jejich pridelovani. IPv6 odstrani jen prvni pricinu - adresu bude dost. To ale nijak nezajisti, ze jich bude dost vzdy tam, kde zrovna budou treba. To by musel existovat automaticky mechanismus, ktery by pridelil (a naroutoval) rozsahy podle potreby.

S NATem plati toto - mam pripojeni pro jeden pocitac -> automaticky (bez jakekoliv lidske komunikace s poskytovatelem) mam pripojeni (sice neplnohodnotne) pro prakticky libovolne mnozstvi pocitacu. To s IPv6 bez NATu obecne nemusi platit.

Krome NATu by tento problem z dostupnych technologii mohl byt resen treba verejnymi tunelovacimi servery, ale to je v jistych ohledech jeste horsi reseni, nez nasazeni NATu (nesmyslny tok dat a z toho vyplyvajici narust latence).

[pavlix]

Globální dostatek by mohl pomoct už z tržního pohledu, stejně jako možnost tunelování.

Je pravda, že když koncový uživatel dostane /128 "rozsah", tak má docela smůlu. Když dostane aspoň /64, tak se s tím dá nějak naložit. Počítat, že každý dostane /48 by asi bylo naivní.

Nejhorší na nedostatku IPv4 adres je to, že poskytovatel nemůže dát slušný rozsah ani když chce.

Jinak s tím automatickým routováním... náznaky jsou, Type 2 routing hlavičky... mobile IPv6... ale nic z toho nemá moc daleko k tomu tunelování.

[MJ]

Je pravda, že když koncový uživatel dostane /128 "rozsah", tak má docela smůlu. Když dostane aspoň /64, tak se s tím dá nějak naložit. Počítat, že každý dostane /48 by asi bylo naivní.

Tohle zrovna řešitelné je. Provideři se při přidělování adres zákazníků musí řídit regulemi toho, kdo jim přidělil jejich blok. V našich končinách tedy obvykle RIPE a ten by mohl mít dost odhodlání na to, aby providery od takových nápadů odradil.

[Käyttäjä 11133]

No může od toho odradit providery. Ale cosi budeme povídat v naší zemi je taky spousta "providerů" jejichž síťová infrastruktura čítá 5 wifi spojů mizerné kvality a jejich jediný spoj do internetu je ADSL od kyslíků... V tom lepším případě mají ještě záložní CDMA...

[pavlix]

Takoví poskytovatelé (spíš sdíleči) mají i hromadu jiných problémů než počet adres. A často horších, věř mi ;).

[Käyttäjä 11133]

[David Jaša]

Ale cosi budeme povídat v naší zemi je taky spousta "providerů" jejichž síťová infrastruktura čítá 5 wifi spojů mizerné kvality a jejich jediný spoj do internetu je ADSL od kyslíků...

&&

Provideři se při přidělování adres zákazníků musí řídit regulemi toho, kdo jim přidělil jejich blok.

=> pokud kyslíci žádné regule nemají, tak ti "provideři" nemají ani co dodržovat.

[Käyttäjä 11133]

Nejhorší na nedostatku IPv4 adres je to, že poskytovatel nemůže dát slušný rozsah ani když chce.

Co je slušný rozsah?

[pavlix]

/64 a lepší. Nemůžeš čekat, že vždycky dostaneš /48...

Ale většinou nepotřebuješ víc než jeden segment... takže /64 + autokonfigurace. Pokud opravdu potřebuješ... tak si to můžeš agregovat jak chceš... ale holt na konfiguraci musíš jinak. Ne že bych chtěl tohle řešení prosazovat, ale jako last resort pro kutily je to fajn.

[Käyttäjä 11133]

Ale já se ptám jaký je slušný rozsah pro IPv4

[Michal Kubeček]

Pro mne je to takový, abych mohl ve své domácí nebo firemní síti jednotlivým segmentům přidělovat rozsahy dostatečné velikosti a abych se obešel bez veškerých maškarád.

Nemám to podloženo žádným seriózním průzkumem, ale jsem docela pevně přesvědčen, že kdyby všichni, kdo si myslí, že mají připojení k Internetu, ho opravdu měli mít, zjistili bychom, že IPv4 adresy už dávno došly…

[pavlix]

IPv4 adresy už dávno došly…

Moje řeč.

[pavlix]

Neboooj, takový jen tak nedostaneš :D. Jinak viz výše.

[thingie]

Pro doma bych to viděl na jeden /24, zhruba. Menší už by pak byly dost jen paklem IP adres, který by se ani nedal nijak nasekat.

[Heron]

Mě by stačilo Céčko.

[petr_p]

Takhle si to představuje RIPE. Ale je pravda, že od LIRu na kraj sítě může být dost daleko na to, aby tam oko našeho všemohoucího nevidělo.

[trekker.dk]

S NATem plati toto - mam pripojeni pro jeden pocitac -> automaticky (bez jakekoliv lidske komunikace s poskytovatelem) mam pripojeni (sice neplnohodnotne) pro prakticky libovolne mnozstvi pocitacu. To s IPv6 bez NATu obecne nemusi platit.

IPv6 adres je opravdu hodně, takže pro poskytovatele připojení pravděpodobně nebude problém přidělovat zákazníkům rovnou rozsahy.

Spíš bych se obával jiné věci a sice toho, že poskytovatelé budou NATem chránit jisté zavaděče pro PC hry a budou si nechat platit za to, že NAT vypnou. Ostatně vzhledem k existenci link-local adres je ještě pravděpodobnější, že ti "lepší" poskytovatelé nebudou jiné než link-local adresy přidělovat vůbec, aby si ušetřili práci a mohli si nechat zaplatit za extra služby.

[pavlix]

Link-local existují i v IPv4, jen jsou nepovinné. Ale toho bych se snad ani tolik nebál... naprostá většina poskytovatelů dává veřejnou IPv4, proč by nedali IPv6. Spíš bych se bál, jaký dají prefix.

Navíc ta změna nebude náhlá, ale postupná. Ještě dlouho bude IPv6 tak nějak navíc... zatímco IPv4 bude ta důležitá.

Jak vyřeší ušlý zisk z různých neměnných veřejných adres a podobných věcí... to nevím, ale až k tomu dojde, bude možná dost jiná situace než teď.

[trekker.dk]

Ale toho bych se snad ani tolik nebál... naprostá většina poskytovatelů dává veřejnou IPv4, proč by nedali IPv6.

Ne zadarmo. To je to, o čem mluvím - že se někdo bude s IPv6 pokoušet napakovat inkasováním za něco, co sám dostal téměř zdarma

[pavlix]

Funguje tady nějaká konkurece, teda aspoň občas :).

Pouhá možnost získat tunel... (o které bude spousta lidí vědět díky tulenům šestky ve čtyřce) levně (možná zdarma)... a tím nějaký /48 rozsah... by mohla odradit poskytovatele od pokusů takový rozsah "prodávat" za vysokou cenu.

Takže sám se spíš přikláním k tomu, že IPv6 téhle situaci více či méně pomůže k lepšímu.

A jestli se na tom zvládnou napakovat výrobci HW, můžou... aspoň zbyde spousta starých routerů na hraní :) třeba s OpenWRT nebo jiným ipv6-enabled OS vhodným pro taková zařízení.

[trekker.dk]

Funguje tady nějaká konkurece, teda aspoň občas :).

To jo, můžu si vybrat mezi kabelovou televizí, která má výpadky v četnosti jednou za čtrnáct dní až jednou za den, wifi, která má konektivitu od té kabelové televize a ADSL od Kyslíků...

Takže sám se spíš přikláním k tomu, že IPv6 téhle situaci více či méně pomůže k lepšímu.

Doufám. Už aby to bylo.

[pavlix]

No vidíš... a co třeba 5GHz wifi napojená skoro na páteř? :). A ještě k tomu full duplex a bez limitů.

To je solidní konkurence, ne? :).

[trekker.dk]

Jj, hezká, bohužel ve zdejších končinách nedostupná...

[pavlix]

Většinou je dostupná tam, kde se do toho někdo pustí. Ale chce to aspoň nějaký osídlení v okolí, aby se to vůbec vyplatilo. Na samotě u lesa to bude drahý :).

[Kroko]

Njn, to dneska je, třeba když si muj zákazník, celkem velká firma stěžovali že jim nejde pošta. Musel jsem jim vysvětlovat, že problém není u nás, ale u výpadků SMTP u O2. Když jsem pak zjišťoval možnost využití SMTP serveru na našich servrech, tak mi od O2 bylo řečeno, že to je blokované a že se musí poslat písemná žádost kamsi do Prahy a že pak možná to povolej pro toho konkrétního zákazníka. Doma jsem toto také musel řešit pro změnu s ISP Skynet kde jsem si musel připlatit 90Kč za pevnou IP adresu abych mohl používat vlastní SMTP server který mam umístěný v datacentru masteru ...

Docela se z tohoto důvodu těším na IPv6 a taky doufám, že to vyřeší i problémy s tím, když se chci připojit na na jiný počítač než mám nastavený na bráně. Platit si další IP adresy se mi nechce, nastavovat různé porty a řešit to jsem moc línej.

[pavlix]

Hlavně jestli máte na té IP adrese v pořádku reverzní záznam, pokud není, některé servery poštu nepřijmou (tuším, že včetně abclinuxu.cz).

[Michal Kubeček]

Link local adresy k tomuto účelu dost dobře použitelné nejsou, to spíš site local. A ty už byly označeny jako deprecated - IMHO právě aby se předešlo pokušení vymýšlet maškarády pro IPv6.

[pavlix]

Spíš myslím, že kvůli propojení několika sites... protože mají náhradu.... do prefixu se tuším vrazí i nějaké náhodné číslo, aby byla malá pravděpodobnost kolizí při propojování privátních sítí.

Ale třeba na tom taky něco je.

[1john2]

zdravim,

mate nekdo prakticke zkusenosti s www.sixXs.net ? je to v nasich krajich pozitelne(pripojeni pres kyslik?) jake typy mailovych adres pozaduji, vim ne freemaily, premyslim kde sehnat lepsi schranku, nikdy sem jinou nez na seznamu nepotreboval

diky za kazde info

[pavlix]

Funguje dobře, ping kolem 60-80 milisekund, bohužel není bližší PoP, třeba časem bude.

Nevím, jak přesně rozeznávají freemaily. Já mám mail na vlastní doméně, tak mě nenapadlo to nikdy řešit.

Je to trochu hraní si s body (vytvoříš tunel, čekáš na body, vytvoříš subnet, ...), počkej si na příští díl... kde budou i příklady nastavení.

[Luboš Doležel (Doli)]

Nevím, jak přesně rozeznávají freemaily.

Kontrolují to ručně, takže snadno. Je důležité mít v cajku DNS, mít sekundární MX server a tím sekundárním MX nesmí být Rollernet.us. Je jedno, že Rollernet je i placená služba, prostě ne a basta.

[pavlix]

Já tuším v cajku DNS neměl, prošlo mi to :).

[Majklík]

Pokud je problém s registrací, tak můžete zkusit třeba tunel od Hurricane Electric - http://www.tunnelbroker.net/ . Nedělají s tím takové opičky jako Sixxs, po novu mají teď POPy i v Londýně a Frankfurtu a také už nabízejí /48 segmenty adres. I latence se drží do Frankfurtu klidně do 30 ms, se sixxsem jsem 50-60 ms s tunelem do Slovinska.

[Stan.]

díky odzkoušeno .. během minuty funkční IPv6 :)

[pavlix]

Díky za info.

[Petr Slansky]

Nechapu proc by si mel koncovy uzivatel zrizovat tunel. Proc jen nepozada sveho ISP o IPv6 pripojeni. IPv6 je zatim postavene na hlavu, takze si tunel zrizuji koncovi uzvatele, kteri chteji experimentovat.

Nicmene, zkuste se zeptat sveho ISP, zda muzute mit IPv6 adresu. Pokud budete mit stesti, odpovi vam jen ze nic takoveho nenabizi, pokud budete mit smulu, budete nejdrive muset vysvetlit co je to IPv6 a k cemu je dobre...

[Käyttäjä 11133]

Jsou provideři, kteří nabízejí IPv6.. I u nás. Já to štěstí bohužel nemám... Ale zase mám dostatek IPv4 adres.

[Kroko]

Stejně nějak nechápu proč to tunelovat, je to jen další část mezi mnou a serverem na který se připojuji a stačí už jen to, že teď mi jdou pakety ze Znojma do Prahy a pak z Prahy do Brna ... :D

Už z tohoto důvodu třeba nemám rád ICQ, aby moje zprávy chodili přes nějaký US server někde v prdeli ....

[pavlix]

Tunel si zřizuje člověk, který nemá možnost nativní konektivity. A většinou si v čechách nezřizuje tunel přes US, ale přes nějaký blízký spolehlivý server.

Já zas nemám rád ICQ, protože si ten server nemůžu ani postavit ani vybrat.

[Kroko]

chci se zeptat na ty rozsahy adres, jestli správně chápu tak je to s přidělováním stejné jako u IPv4, tedy případ:

Mám domácí síť která je připojena k internetu přes ISP 1, dále pak mam několik serverů umístěných v datacentru v jiném městě přes ISP 2. Od ISP 1 dostanu přidělený rozsah řekněme /24 do kterého dam počítače ve své domácí síti.

1/ IP adresy z tohoto rozsahu nemohu použít u těch serverů které jsou připojeny jednak přes jiného ISP tak i geograficky úplně jinde. Musim si tak u ISP 2 požádat o přidělení druhého rozsahu řekněme /48 pro servery. 2/ Mohu použít rozsah přidělený ISP 1 i pro servery připojenými přes ISP 2.

2. možnost je dle mého názoru blbost (pokud nepoužiji nějaké postupy jak to obejít). Potřebuji si tuto domněnku potvrdit.

[pavlix]

Hlavním způsobem přidělování adres je agregování na úrovni ISP... tzn ISP dostane rozsah, který dál přerozděluje.

Dá se obejít například přes IPv6 mobility (na to se ale používá směrování přes router na síti, kam ten IPv6 prefix patří). Pak tuším existovaly nějaké možnosti přidělení na ISP nezávislého rozsahu, ale je to dost nepraktické.

[Kroko]

takze proste 1. moznost, jak jsem psal, 2. je blbost, to jsem chtel vedet :)

[pavlix]

Jj, přesně tak :), omlouvám se za zdlouhavou odpověď, nejsi z Ostravy nebo tak nějak? :D

[kralyk z abclinuxu]

Myslim že nasazení IPv6 se zuby nehty snaží zdržovat různé protipirátské organizace.
Si jen představte ten rozkvět Bittorrentu kdyby každý měl public IPv6...

[pavlix]

Nojo, tak se bude bittorrent blokovat u ISP, stejně je to už dneska relativně běžná praxe.

Sice se neblokuje kvůli protipirátským organizacím... ale kvůli tomu, že většina bittorrent programů se snaží naprosto bezostyšně zablokovat linku svými pakety, nejdejbože, když je to na 2.4GHz wifi (sice nevím, jak to souvisí s 2.4kou... ale zkušenosti mých známých).

[trekker.dk]

většina bittorrent programů se snaží naprosto bezostyšně zablokovat linku svými pakety

Zdá se ti, že je tady málo nesmyslných blábolů, že přihazuješ další? To co říkáš, je jako kdybys řekl, že wget/seamonkey/cokoliv jiného se snaží bezostyšně zablokovat linku svými pakety.

[Michal Kubeček]

A ne snad? :-)

[trekker.dk]

No vlastně jo.

Když se to tak vezme, tak je vlastně potřeba všechny programy, které něco umí stahovat z netu, zablokovat, aby se nepřetěžovala linka.

[Michal Kubeček]

Novodobá Hospoda na mýtince: dědeček poskytoval připojení k Internetu, ale lidi mu přes to posílali data… :-)

[pavlix]

V posílání dat problém nebyl, na to funguje bežné omezování toku dat.

[pavlix]

wget mi linku nezablokuje.

Sorry, je to příklad z praxe, ne blábol.

Zeptej se pár wifi poskytovatelů, s čím mají největší problémy.

[Grunt]

Zdá se ti, že je tady málo nesmyslných blábolů, že přihazuješ další?

Nesmyslný blábol to není určitě.

To co říkáš, je jako kdybys řekl, že wget/seamonkey/cokoliv jiného se snaží bezostyšně zablokovat linku svými pakety.

Jenže HTTP využívá na jeden soubor jedno TCP spojení, které se dá krásně řídit díky technice okna po celé délce spojení a snaží se používat max velikost paketu.

[pavlix]

Nesmyslný blábol to není určitě.

Děkuji ti náčelníku, že jsi se mě zastal.

Njn, někteří lidé holt reagují bez rozmyslu, budiž mu odpuštěno.

Jenže HTTP využívá na jeden soubor jedno TCP spojení, které se dá krásně řídit díky technice okna po celé délce spojení a snaží se používat max velikost paketu.

Jak je to s BT, ten používá nějakou nesmyslně malou velikost?

A tím pádem megabajt přes bittorrent je oproti megabajtu přes http obrovská zátěž?

[Grunt]

Jak je to s BT, ten používá nějakou nesmyslně malou velikost?

Nesmyslně malou určitě ne, ale&hellip
BT má dvě části, TCP na tahání a komunikaci a UDP na DHT:

DHT se používá na vyměňování Hashů mezi všemi peery(možná kecám, moc jsem to nestudoval). No když je dostatek peerů, už to dovede vyprodukovat docela slušnou rate. A omezování a UDP, o tom asi netřeba mluvit. Velikost paketů tak mezi 80-500B.

No a pak TCP část. Pokud stahujete řekněme album a to obsahuje 20 skladeb o velikosti řekněme 2-3MB, tak ta je ještě rozkouskována na menší části (na Wikipedii je psáno, že většinou 250kB, ale já se setkal jenom s ještě menšími), které se stahují zároveň od všech peerů(nevím jestli se vždy jedna část musí stahovat právě od jednoho klienta nebo jestli se může stahovat jedna část i od více klientů) a na každou část se vytvoří samostatné TCP spojení. A než se vůbec TCP dostane z pomalého startu, tak je po spojení. No a pak jsou tu ještě komunikační pakety, které jsou malé(já jsem naměřil celkovou velikost tak kolem 50-150B, takže i hlavičky od linkové po transportní vrstvy jsou větší), že se pro blbých 50B dat musí odeslat tak 6paketů než se vůbec naváže a zase ukončí spojení. Nedejbože pokud je některý paket zahozen. To se potom musí 5x znova odesílat než vůbec projde.

Kdybych měl po ruce kus papíru, určitě bych to nastínil lépe. Celé je to spíše shoda různých náhod.

A tím pádem megabajt přes bittorrent je oproti megabajtu přes http obrovská zátěž?

Zkuste si stáhnout přes HTTP jeden 1MB soubor a pak ten samý soubor ale rozdělený do 20 částí a zároveň. Zvláště pokud je na cestě k tomu všemu ještě pomalí HW. On vůbec celé určování propustnosti zařízení MB/s mi přijde trochu přitažené za vlasy.

[Luboš Doležel (Doli)]

DHT se používá na vyměňování Hashů mezi všemi peery(možná kecám, moc jsem to nestudoval).

DHT slouží pro hledání nových peerů a k získání metainformací (přes DHT je možné stáhnout i samotný torrent). Hashe jsou v .torrent souboru.

a na každou část se vytvoří samostatné TCP spojení.

Vážně? A proč by se to dělalo?

A než se vůbec TCP dostane z pomalého startu, tak je po spojení.

Co?

že se pro blbých 50B dat musí odeslat tak 6paketů než se vůbec naváže a zase ukončí spojení

To je jen na začátku spojení. Omezte počet spojení a je to.

Zkuste si stáhnout přes HTTP jeden 1MB soubor a pak ten samý soubor ale rozdělený do 20 částí a zároveň.

To můžu udělat klidně a problém to nebude. Hádám, že se o něco sníží efektivita, ale to je spíš můj problém.

[Grunt]

Vážně? A proč by se to dělalo?

Protože každou část stahuje z jiné IP.

A než se vůbec TCP dostane z pomalého startu, tak je po spojení.

Co?

TCP - od Techniky okna až dolů.

To je jen na začátku spojení. Omezte počet spojení a je to.

A na konci. A technika zpoždění odpovědi byla asi také tvůrcům neznámá jelikož půlka z toho jednoho spojení jsou jen potvrzení(Na druhou stranu, ale nevím co je to za data).
AD. Omezení počtu spojení:Spíše počet paketů, protože i do jednoho spojení se dá narvat 1000paketů. Mě je to samozřejmě jasné, ale nejde o mě ale o ty ostatní "ISP".

BTW. jakékoliv omezování jinde než na AP klientů to potom ještě zhoršuje, protože se ty pakety musí odesílat znovu.

To můžu udělat klidně a problém to nebude. Hádám, že se o něco sníží efektivita, ale to je spíš můj problém.

A problém tvého ISP, zvláště pokud má pomalí HW a neefektivní návrh sítě.

[Luboš Doležel (Doli)]

Takže polopatě. Na začátku si otevře cca 100 spojení a tento počet udržuje. Určitě se neotevírá nové spojení pro každý chunk. To je blbina.

Start TCP spojení je pomalý možná tak na nějaké mizerné lince s vysokou latencí.

A technika zpoždění odpovědi byla asi také tvůrcům neznámá jelikož půlka z toho jednoho spojení jsou jen potvrzení

Není posílání ACKů spíš úkolem jádra než nějakého programu?

A problém tvého ISP, zvláště pokud má pomalý HW a neefektivní návrh sítě.

Tak to je v podstatě jeho problém a pokud by se problém opravdu objevil, jdu jinam.

[pavlix]

Tak to je v podstatě jeho problém a pokud by se problém opravdu objevil, jdu jinam.

Tak kvůli bittorrentu bych asi providera neměnil.

[kralyk z abclinuxu]

... tak ta je ještě rozkouskována na menší části (na Wikipedii je psáno, že většinou 250kB, ale já se setkal jenom s ještě menšími), které se stahují zároveň od všech peerů(nevím jestli se vždy jedna část musí stahovat právě od jednoho klienta nebo jestli se může stahovat jedna část i od více klientů) a na každou část se vytvoří samostatné TCP spojení.

To není žádná pravda. Zaprvý ty kousky jsou většinou o dost větší než 250kB. Nevim odkud jste stahoval torrenty, já sem se sekal s nejmenšími o velikosti 1MB, obvykle pak 4 a více MB. Zadruhý stahuje se dycky od jednoho peeru jeden kousek a pak se sčekuje hash toho kousku. Najednou se sice stahuje víc kousků, ale každej je jinej a (imho) od jinýho peeru.

Zkuste si stáhnout přes HTTP jeden 1MB soubor a pak ten samý soubor ale rozdělený do 20 částí a zároveň. Zvláště pokud je na cestě k tomu všemu ještě pomalí HW. On vůbec celé určování propustnosti zařízení MB/s mi přijde trochu přitažené za vlasy.

BT není na tahání 1MB souborů, ale stokrát až tisíckrát větších. A říct že 1MB soubor se rozkouskuje na 20 čaástí je holej nesmysl, žádný rozumný tvořič torrentů by to neudělal...

[Ondrej 'SanTiago' Zajicek]

A než se vůbec TCP dostane z pomalého startu, tak je po spojení.

Coz by byla z hlediska zahlceni linky vyhoda - v takovem pripade by to stahovalo pomaleji, nez je mozne.

[trekker.dk]

Děkuji ti náčelníku, že jsi se mě zastal.

Njn, někteří lidé holt reagují bez rozmyslu, budiž mu odpuštěno.

Kecy sem, kecy tam, ale informační hodnota je nula.

[pavlix]

Nechtěl jsem tě urazit.

[trekker.dk]

Nechtěl jsem tě urazit.

vs.

Sám seš blábol.

Schíza je mrška, pozor na ní...

[pavlix]

Zatím jenom střílíš, co všechno je blábol... fakt jsem ti chtěl jenom taktně naznačit, že je někdy lepší trochu víc naslouchat... a případně dávat své pochybnosti najevo trochu diplomaticky. Zvlášť, když už ses tady jednou netrefil.

Jinak jestli se tímhle necháš urazit, tak to máš těžký :D.

[trekker.dk]

a případně dávat své pochybnosti najevo trochu diplomaticky.

To většinou dělám. Jenže když se neustále opakují ty samé nesmysly (jak o torrentu, tak o IPv6), tak už se s diplomacií nezatěžuju.

Zvlášť, když už ses tady jednou netrefil.

Připouštím, že je to možné... nicméně pokud slovem tady nemáš na mysli celé abclinuxu, ale tuhle konkrétní diskuzi, tak bych rád věděl, kde to bylo mělo být.

[pavlix]

Reakce na mojí poznámku o problémech s torrentem, jestli sis nevšiml, tak další přišli i s docela detailním a rozumným vysvětlením, proč a kdy ty problémy nastávají.

Torrent se u spousty lidí projevuje dost nepříjemným způsobem, přečti si třeba příspěvek od the.maxe. To je fakt, na tom nic nezměníš. Dokonce ani sebelepší specifikace (tu nehodnotím).

A buď můžeš na to reagovat, že je to blábol, pak budeš za blba (zvlášť u lidí, kteří na problém už narazili), nebo můžeš reagovat nějak smysluplně. Vždycky máš na výběr :).

[trekker.dk]

Torrent se u spousty lidí projevuje dost nepříjemným způsobem, přečti si třeba příspěvek od the.maxe. To je fakt, na tom nic nezměníš.

To je fakt, který nehodlám popírat. Tvrdím ale to, že to není chyba torrentu, ale sítě, která nezvládá to, co by měla (například sdružování paketů do jednoho rámce, což by té síti značně odlehčilo)

Fakt, na kterém nic nezměníš ty, je, že i na 2.4GHz se nechá torrent provozovat, aniž by to způsobovalo problémy.

[pavlix]

To je fakt, který nehodlám popírat.

A o tom přesně byl můj příspěvek, který jsi označil za blábol.

Tvrdím ale to, že to není chyba torrentu, ale sítě, která nezvládá to, co by měla (například sdružování paketů do jednoho rámce, což by té síti značně odlehčilo)

Fajn, začínáme mluvit k věci :) (ať už je to tak jak píšeš nebo ne). +1

Zajímalo mě, nakolik je na vině samotná specifikace, na kolik jsou to konkrétní implementace... a nakolik jiné důvody.

Fakt, na kterém nic nezměníš ty, je, že i na 2.4GHz se nechá torrent provozovat, aniž by to způsobovalo problémy.

LOL

[trekker.dk]

A o tom přesně byl můj příspěvek, který jsi označil za blábol.

Aha, v takovém případě jsi tom v tom příspěvku měl napsat. Větu

většina bittorrent programů se snaží naprosto bezostyšně zablokovat linku svými pakety

si málokdo vyloží jako "Torrent se u spousty lidí projevuje dost nepříjemným způsobem"; to první jsi napsal na začátku, to druhé až teď.

Zajímalo mě, nakolik je na vině samotná specifikace, na kolik jsou to konkrétní implementace

Pokud mluvíš o wifi, tak specifikace to umožňuje, jenže je to náročnější na výpočetní výkon (pakety se musí porovnávat, jestli míří na stejný bod v síti), paměť (pokud chci čekat, musím neodeslaná data někde schovat), samozřejmě i na programování... zjednodušeně řečeno se to prodraží, tj. levné šmejdy to neumí a nedělají.

[pavlix]

To slovo "většina" tam možná trochu přečuhuje...

Tou specifikací jsem myslel bittorrent.

[pavlix]

Fakt, na kterém nic nezměníš ty, je, že i na 2.4GHz se nechá torrent provozovat, aniž by to způsobovalo problémy.

Nejde o to, aby to šlo. Jde o to, aby měl ISP chuť to vůbec dělat... když to může vypnout nebo omezit počet spojení na IP adresu (což má pro většinu uživatelů torrentu podobný efekt).

[Grunt]

Kecy sem, kecy tam, ale informační hodnota je nula.

Vždyť fórum je od toho aby se na něm kecalo, nebo se zase mýlím?

[Grunt]

Kecy sem, kecy tam, ale informační hodnota je nula.

Vždyť fórum je od toho aby se na něm kecalo, nebo se zase mýlím?

Fórum…chtěl jsem říct diskuse.

[trekker.dk]

Jenže HTTP využívá na jeden soubor jedno TCP spojení, které se dá krásně řídit díky technice okna po celé délce spojení a snaží se používat max velikost paketu.

Slyšel jsi někdy o segmentovém stahování, tedy že si soubor rozdělím na několik souborů a každý kousek stáhnu zvlášť? Když najdu víc zrcadel, mám HTTP torrent.

Vzhledem k tomu, že servery jsou zpravidla rychlejší, než ti dá linka od poskytovatele, se tohle nedělá. Kdyby jo, budou wifi rádobyISP brečet nad segmentovým HTTP stejně jako teď brečí nad torrentem.

Jenže HTTP využívá na jeden soubor jedno TCP spojení, které se dá krásně řídit díky technice okna po celé délce spojení a snaží se používat max velikost paketu.

Jak se HTTP může snažit používat maximální velikost paketu, to teda nechápu. Webserver, který posílá data, je ze svého pohledu cpe do socketu; z principu může ovlivnit, velikost okna tak, že tu a tam pošle malý kousek dat a jinak nic, to se ale bude snažit použít minimální velikost paketu.

Obráceně (tedy server pere do spojení, co se do něj vejde) to závisí na jádře, jak velké pakety udělá. Mýlím se? Nechám se klidně poučit.

[the.max]

Tim znamym myslel pavlix me.. Tazke aby bylo jasno. Mezi lidmi jsou bittorrent klienti hojne rozsireny, pouzivany a oblibeny diky sve jednoduche instalaci a obsluze. Problem nastava tehdy, pokud si clovek zvoli "prasackeho" klienta, ktery neni schopen normalne komunikovat (tim myslim posilat packety o rozumne velikosti) a misto toho posila packety o velikosti 100b. Jiste si dokazes spocitat,z e takovyto packet ma delsi hlavicku, nez dulezita data. A aby ten program byl stejne rychly jako ten, ktery posila packety o velikosti okolo 1400b, musi jich poslat temer 30x tolik. Co to znamena na bezdratu? Pomerne jednoducou vec. Specialne 2.4GHz levna a u nas veeeeeeelmi hojne rozsirena APcka s cipsety realtek zazivaji docela krusne casy. Kdo se v bezdratovych technologiich orientuje vi, ze je mnohem eektivnejsi posilat jeden velky packet nez 30 malych a to proto, protoze wifi zarizeni pracuji jako half-duplex zarizeni, tazke bud vysilaji, nebo prijimaji. Po kazdem odeslanem packetu se e prepnou na prijema cekaji az jim protistrana odpovi,z e packet dorazil. to to prepinani zabere nejaky cas a tez i systemove prostredky. Jiste si kazdy domysli, co se stane, kdyz se sejde treba 5 lidi s takovymto klientem na jednom APcku. Muzes namitnout, proc tedy konkretnimu clovekovi nereknu aby pouzival jineho klienta... protoze ten clovek mi to odkejve, ale stejne dal bude pouzivat toho "sveho" klienta, protoze se prece nebude ucit ovladat nejaky jiny. A i treba proto, ze ten jiny a lepsi klient je mene barevny a ma jednodussi ikony...V topto pripade je resenim bittorrent zakazat, protoze kvuli 2ma lidem si nenecham od dalsich 10ti nadavat... Jeste stesi,ze s 2.4kou jsme zkoncili

[Grunt]

Jeste stesi,ze s 2.4kou jsme zkoncili

Na něčem jiném je situace lepší?

[Kroko]

bohužel i na 5tce už to začíná být docela nahusto :(

[Grunt]

bohužel i na 5tce už to začíná být docela nahusto :(

Také si myslím, že je to jen oddálení problému.

[Käyttäjä 11133]

Že by na licencovaných frekvencích?

[Grunt]

Že by na licencovaných frekvencích?

5Ghz je mám pocit bezlicenční pásmo(pokud se tedy bavíme o 802.11a) a nebo se mýlím?

[Käyttäjä 11133]

Byla to reakce na

Na něčem jiném je situace lepší?

[Grunt]

Jo takto. No je pravda, že faktor rušení mizí, ale spousta jiných zůstává a nebo se jen oddaluje.

[trekker.dk]

A aby ten program byl stejne rychly jako ten, ktery posila packety o velikosti okolo 1400b, musi jich poslat temer 30x tolik.

No a to je právě blábol - bittorrent ani jeho klienti neposílají data v žádných 100B paketech. Klienti posílají data do socketu a jak bude packet velký, to si určí jádro jako takové. Ty malé pakety jsou z největší části dodatečné - režijní - informace.

[pavlix]

Sám seš blábol.

[trekker.dk]

Děkuji ti, že jsi mě i všem ostatním přítomným laikům vysvětlil, v čem přesně se mýlím.

[pavlix]

No... buď v tom, že se neposílají 100B pakety... nebo v tom, že v těch 100B paketech jsou režijní informace. Vyber si :).

Tvým psaním o tom, co je blábol, ze sebe akorát uděláš blbce. Ostatní se většinou snaží psát trochu na úrovni. Občas se nepovede.

[trekker.dk]

Ostatní se většinou snaží psát trochu na úrovni.

Někteří by se radši měli snažit pořádně si přečíst to, na co reagují.

No... buď v tom, že se neposílají 100B pakety...

Já jsem nepsal, že se neposílají. Já jsem psal, že klienti neposílají 100B pakety. To totiž nemůžou. Uznávám, že jsem softwaru, kterej komunikuje po síti, nenapsal moc, ale pamatuju si na nějaký věci jako socket, send() a podobné... na druhou stranu si nepamatuju nic jako send_packet; dokonce silně pochybuju, že by něco takového mohl udělat někdo jiný, než root.

Klienti neposílají pakety. Klienti posílají data a pakety z nich vyrábí jádro.

...nebo v tom, že v těch 100B paketech jsou režijní informace.

Jasně - torrent funguje bez režie, všichni klienti jsou slinkovaní s libvěštec a potřebné informace jako kdo má jaká data k dispozici si domyslí...

[pavlix]

Řešíš kraviny... jestli to posílá systém nebo program je mi upřímně jedno.

Systém posílá paket, protože to po něm aplikace chce. Jasně, TCP se k aplikaci chová jako datový proud, UDP zase ne.

Ostatní se bavili o tom, co se posílá v rámci bittorentu, ne o tom, která část systému co z toho zajišťuje.

[trekker.dk]

Řeším tohle:

Problem nastava tehdy, pokud si clovek zvoli "prasackeho" klienta, ktery neni schopen normalne komunikovat (tim myslim posilat packety o rozumne velikosti) a misto toho posila packety o velikosti 100b.

Protože to je prostě nesmysl. Ano, systém posílá paket, protože to po něm aplikace chce. To důležité ale je, že klient nemůže posílat pakety o "rozumné velikosti", když prostě ta data nemá (když chce třeba druhé straně říct jenom něco jako "Ahoj, pošleš mi chunk 259?)" Na to nepotřebuje plných 1500B a proto pošle malý paket.

Tvrzení, že torrent je špatný, protože posílá malé pakety na přenášení dat, je principiálně nesmyslné, takže máš pravdu, řeším kraviny, ale napsal je někdo jiný.

Jasně, TCP se k aplikaci chová jako datový proud, UDP zase ne.

Z hlediska programátora se víceméně oba chovají jako datový proud, akorát u UDP nemáš jistotu, že ti přišlo všechno a pokud chceš nějaké potvrzování, musíš si ho naprogramovat sám. Při programování můžeš používat ty samé funkce (send/recv) A v kontextu toho, o čem se bavíme, je to úplně fuk.

[pavlix]

Viz dále, co píše SanTiago.

[trekker.dk]

Četl jsem. Ty si zase najdi, co píše Doli + ty statistiky, které jsem poslal já - na tom, co se děje přes UDP zase tolik nezáleží...

[Grunt]

Příloha:

• BT (106 bytů)

Tak to mám snad nějakého vadného BT klienta či co. Nic, s diskusí končím dokud nebudu mít po ruce nějaká reprezentativní data.

[the.max]

Nesnaz se mi tu vykladat neco o tom, ze klient si povida s druhou stranou jen po 100b packetech a jen zada rpotistranu aby mu neco poslala. Dal jsem si tu praci,z e jsem si nainstaloval zavadec na hry, inkriminovaneho klienta jsem nainstaloval a zacal jsem stahovat. jsem si 100%ne jisty, ze ten klient neodeslal packet dlesi nez 122b!!! stahoval jsem cca 600mb CD, ale abych tech 600mb stahl, tak jsem zbytecne navic musels tahnout dalsich cca 1400mb... Je to sice jiz delsi doba, mozna ten kient uz neexistuje, mozna se uz chova slusne, nevim, ale je mi to uplne u pr***e.

[trekker.dk]

jsem si 100%ne jisty, ze ten klient neodeslal packet dlesi nez 122b!!!

A sdílel jsi? Respektive stáhl si od tebe někdo kus toho CD?

stahoval jsem cca 600mb CD, ale abych tech 600mb stahl, tak jsem zbytecne navic musels tahnout dalsich cca 1400mb...

Velikost odesílaných paketů tvůj stahující inkriminovaný klient neovlivní...

[Luboš Doležel (Doli)]

Dal jsem si tu praci,z e jsem si nainstaloval zavadec na hry, inkriminovaneho klienta jsem nainstaloval a zacal jsem stahovat. jsem si 100%ne jisty, ze ten klient neodeslal packet dlesi nez 122b!!!

Aby se přes BT posílala data o tak malých blocích, to nemůže žádný normální klient dělat. To musela být nějaká závažná porucha.

ale abych tech 600mb stahl, tak jsem zbytecne navic musels tahnout dalsich cca 1400mb

Takže 233% overhead? Ale kdeže... maximálně nějaké procento.

[kralyk z abclinuxu]

abych tech 600mb stahl, tak jsem zbytecne navic musels tahnout dalsich cca 1400mb...

Tak to je hooodně přitažené zavlasy. Je sice možné, že v jedné konkrétní situaci s nějakým hoodně bugozním klientem se to stalo, ale rozhodně to nejde zobecňovat.

Nadruhou stranu je pravda, že dost klientů se chová přinejmenším podivně.

[Ondrej 'SanTiago' Zajicek]

Uznávám, že jsem softwaru, kterej komunikuje po síti, nenapsal moc, ale pamatuju si na nějaký věci jako socket, send() a podobné... na druhou stranu si nepamatuju nic jako send_packet;

Pokud klient komunikuje pres UDP, pak je rozcleneni dat do jednotivych paketu na nem. Viz sendmsg().

[the.max]

Me je uprimne jedno jestli ty 100b packety posila klient, socket, nebo treba martan. Me zajima to, ze nasledkem toho mi volaji dalsi lidi pripojeni na stejne AP ze jim nefunguje internet a kdyz jo tak strasne pomalu.Problem jsem nasel v tom, ze jeden clovek pripojenej na toto APcko ma psustenyho bittorrent klienta kterej se chova prasacky. Proc tedy jeden klient umi packety okolo 1500b a jina s****a dela 30x tolik 100b???

Nicmene tohle je uz dost offtopic...

[the.max]

videl jsi nekdy jak 40 lidi s bittorrent klientem dokaze srazit do kolen router s 2GHz opteronem a serverovou deskou, serverovyma sitovkama (zadnej raltek) ,2Gb pameti...? Asi ne.. ja v prvnich chvilich myslel, ze mi na siti strasi.

[Ondrej 'SanTiago' Zajicek]

Nepretekla ti conntrack tabulka? Snadna pomoc - nastavit ji vetsi, nebo ji vubec nezapinat (pokud neni treba).

[pavlix]

Tuším, že ten jeho router ji potřeboval (maškaráda).

[Luboš Doležel (Doli)]

Neviděl. Jsem na síti, kde je shaper Packeteer a zvládá stovky uživatelů. Shaper je připojen optikou do Prahy 1 Gbit/s. Problémy neexistují.

[Grunt]

videl jsi nekdy jak 40 lidi s bittorrent klientem dokaze srazit do kolen router s 2GHz opteronem a serverovou deskou, serverovyma sitovkama (zadnej raltek) ,2Gb pameti...? Asi ne.. ja v prvnich chvilich myslel, ze mi na siti strasi.

Nechci být rýpavý, ale to je možná přesně ten problém ISP. Po vesnicích rozdají RB1XX-ky(vždyť je tam pár klientů - to musí přece stačit) a všechno to slejí do jednoho centrálního routeru kde nasadí nějaké Core2Dup s queues, ovšem to mi přijde jako chyba. Omezovat(alespoň odesílací směr) by se měl už na APčkách klientů, protože takt o torrenty zaserou celou cestu až k centrálnímu shaperu. A také nevím proč všichni omezujete počty spojení, které tak max. žerou paměť na routerech se zapnutým conntrackem.(I do jednoho spojení můžu narvat 1000p/s)

[pavlix]

A také nevím proč všichni omezujete počty spojení,

Nejspíš proto, že mají vyzkoušeno, že pak ten problém nenastane.

[Luboš Doležel (Doli)]

Omezovat(alespoň odesílací směr) by se měl už na APčkách klientů, protože takt o torrenty zaserou celou cestu až k centrálnímu shaperu.

Teď se nezasvěceně ptám ostatních, zda je to opravdu možné? Tohle by se dalo samozřejmě čekat u UDP, ale u TCP? Shaper ty pakety zahodí nebo zbrzdí a klient zpomalí okamžitě sám.

[Dan Ohnesorg]

Existuji klienti a potom P2P aplikace, ty druhe se chovaji neskutecne blbe. Napr. maji zjisteno, ze na ADSL vetsinou probiha shaping tak, ze kdo ma vice TCP spojeni, urve relativne vice pasma. A tak pouzivaji tolik TCP spojeni, kolik ma masina portu.

Nicmene na strane AP se da oriznout neco malo, protoze vetsina komunitnich siti funguje tak, ze se lidi deli o celou linku a tak kdyz se to zareze natvrdo na AP, tak je zbytecne velky kus linky nevyuzity.

[trekker.dk]

Napr. maji zjisteno, ze na ADSL vetsinou probiha shaping tak, ze kdo ma vice TCP spojeni, urve relativne vice pasma. A tak pouzivaji tolik TCP spojeni, kolik ma masina portu.

Jestli to spíš nebude z toho důvodu, že každé to spojení vede k někomu jinému... u P2P bych to docela očekával.

[Grunt]

sice nevím, jak to souvisí s 2.4kou... ale zkušenosti mých známých

Spíše je to neznalostí těch co ty spoje dělají. Většinou omezují až na centrálním routeru kdy je ke klientovi cesta přes 3 další routery spojené také Wi-Finou a jelikož BitTorrent(resp. rozšíření pro BT DHT bez kterého BT nefunguje) používá UDP a to stylem "perem do linky co se vleze", tak se zaplní buffery na routerech po cestě a celá linka jde do kopru. Nemluvě o tom, že když už i omezují u klientů odesílací směr, tak tam většinou dají pouze omezení na zakoupenou klientovu rychlost a pak to pozabíjí počty paketů.

[Käyttäjä 11133]

t(resp. rozšíření pro BT DHT bez kterého BT nefunguje)

Ale notak. Takhle lhát, že se nestydíš...

[Grunt]

t(resp. rozšíření pro BT DHT bez kterého BT nefunguje)

Ale notak. Takhle lhát, že se nestydíš...

Dobře, upřesním:Funguje ale nestahuje, protože ostatní peerové odmítají bez zaplého DHT komunikovat. A na co někomu bude BitTorrent klient, který nestahuje?

[Käyttäjä 11133]

Minimálně já lidi bez DHT neodmítám... Takže asi tak.

[Grunt]

Minimálně já lidi bez DHT neodmítám... Takže asi tak.

, tak jo. Řeknu všem ať tahají od Stopky. Bohužel jsi výjimka.

[Michal Kubeček]

Neřekl bych. V OpenSuSE je KTorrent bez podpory DHT (kvůli právníkům) a stahuje hladce nejen od Stopky…

[xm]

Proč je v OpenSUSE KTorrent bez podpory DHT? Co si to to stupidní právní oddělení vymyslelo?

[Michal Kubeček]

Detaily neznám. Jen si pamatuji, že když jsem se snažil zjistit, proč je to zkompilované bez DHT, nalezl jsem v bugzille u příslušné chyby odpověď, že je to "kvůli právníkům", ale bez bližších podrobností.

[Luboš Doležel (Doli)]

1) Takového klienta jsem ještě neviděl

2) Těch UDP paketů je minimum

[Grunt]

1) Takového klienta jsem ještě neviděl

Skus si zapnout nějakého BT klienta a vypnout DHT. Mě v Azureusovi vždy naskákalo ve Swampu asi 15 IP adres a hned zmizli. A takto pořád dokola. Netvrdím, že odmítají všichni, ale při mém testu většina.

2) Těch UDP paketů je minimum

To bych tedy netvrdil(zvláště když se stahuje více souborů najednou). A s TCP částí to také není nijak slavné(vysvětleno trošku výše).

[Luboš Doležel (Doli)]

Skus si zapnout nějakého BT klienta a vypnout DHT. Mě v Azureusovi vždy naskákalo ve Swampu asi 15 IP adres a hned zmizli. A takto pořád dokola. Netvrdím, že odmítají všichni, ale při mém testu většina.

Tak se neomezujte na vaše mizerné odhady a podívejte se do dokumentace. DHT slouží k vyhledání dodatečných peerů oproti tomu, co je k dispozici z trackeru. Jediné, co se dělo u vás, bylo to, že dané peery nebyly dostupné.

A proč by proboha nějaký BT klient odmítal nové spojení když druhá strana nenabízí DHT? Jaký důvod by pro to měl?!

To bych tedy netvrdil(zvláště když se stahuje více souborů najednou). A s TCP částí to také není nijak slavné(vysvětleno trošku výše).

To bych zatraceně tvrdil. To už je podruhé, co se mě tu někdo snaží přesvědčovat o tom, že BT přenáší kdovíjaké veliké množství UDP paketů, přitom to *není pravda*.

[Grunt]

Příloha:

• Obrazovka.png (177383 bytů)

DHT slouží k vyhledání dodatečných peerů oproti tomu, co je k dispozici z trackeru. Jediné, co se dělo u vás, bylo to, že dané peery nebyly dostupné.

Asi to tak opravdu bude, protože jsem zkusil jiný Torrent a "stahovalo to". Sice tak rychle, že blikání síťovky bych mohl i počítat(někdy i půl minuty tma), ale to mohlo být i tím, že už nebylo potřeba odesílat UDP pakety a nebo že je nějaký špatný torrent. Než něco vyvodím tak se radši půjdu zeptat nějakého tahače, jelikož jsem BT zapl po páté v životě. A nebo začnu u lidí DHT filtrovat a uvidím co na to budou říkat.

To bych zatraceně tvrdil. To už je podruhé, co se mě tu někdo snaží přesvědčovat o tom, že BT přenáší kdovíjaké veliké množství UDP paketů, přitom to *není pravda*.

Viz příloha.

[Grunt]

Viz příloha.

A to byl jeden torrent. Opravdu někdy doporučuji přesměrovat na svůj počítač stream od tahče který má obrazovku plnou torrentů od shora dolů a pak si do toho pustit Wireshark. Můj to neustál.

[Luboš Doležel (Doli)]

Tak stahujte něco, co má funkční tracker a dostatek zdrojů. Spíš než že by to nám zázračně fungovalo bez DHT je u vás problém.

Viz příloha.

A to je jako hodně?

[Grunt]

A to je jako hodně?

Vzhledem k TCP?

[Luboš Doležel (Doli)]

Jo. Tohle je jen nějakých 10p/s. Na TCP to při zátěži lítá mnohem víc.

[Grunt]

Jo. Tohle je jen nějakých 10p/s.

, a to jsi vypočetl z toho obrázku jak?

Na TCP to při zátěži lítá mnohem víc.

Opak netvrdím, ale: a)Dá se to mnohem lépe řídit. b)Vždyť se také u BT neodvolávám jen na malé UDP, ale jako na jeden z faktorů.(Nicméně díky tobě již eliminovaných faktorů, za což jsem samozřejmě náležitě vděčný.

[Luboš Doležel (Doli)]

a to jsi vypočetl z toho obrázku jak?

Já ti ani nevím, na matiku jsem nikdy moc nebyl, ale když ten capture běží 75 sekund a za tu dobu projde 825 UDP paketů, tak 825/75 = 11.

Opak netvrdím, ale: a)Dá se to mnohem lépe řídit. b)Vždyť se také u BT neodvolávám jen na malé UDP, ale jako na jeden z faktorů.(Nicméně díky tobě již eliminovaných faktorů, za což jsem samozřejmě náležitě vděčný.

Řekl bych, že ten protokol funguje docela dobře. Vždycky je co vylepšovat, ale není to zle udělané.

[pavlix]

Protokol je možná dobrý, ale v praxi to na síti dělá psí kusy, ať už za to může program nebo slabá linka. Chápu, že si někteří ušetří práci s detailním studováním protokolu a radši zaškrtnou políčko "zakázat".

[pavlix]

Vypadlo mi slovo "občas".

[Grunt]

Já ti ani nevím, na matiku jsem nikdy moc nebyl, ale když ten capture běží 75 sekund a za tu dobu projde 825 UDP paketů, tak 825/75 = 11.

To by platilo ,kdybych se sniffováním jsem začal v ten moment kdy jsem zapl Azureus. A navíc já nejsem určitě reprezentativní vzorek, skusím sehnat dump z nějakého hraničního routeru sítě s běžnými BT uživateli ať můžeme rozvinou tlachání i o nějaká fakta.

[trekker.dk]

Jeden příklad - pár statistik pořízených iptrafem při stahování přes torrent

Podle protokolu:

Protokol - příchozích paketů - příchozích bytů - odchozích paketů - odchozích bytů
TCP/IP     2189                2877526           1745               191219
UDP/IP       19                   4854             17                 2124

Pro doplnění - hodnoty příchozích paketů za sekundu a odchozích za sekundu byly přibližně 50. Jestli teda v torrentu UDP převažuje, tak se asi musí nějak maskovat, jinak to nechápu.

Podle velikosti paketu:

1-75B: 9687    76-150B: 1017    151-225B: 203    226-300B: 184    301-375B: 230
1426-1500+: 10026

Ostatní velikosti neuvádím, bylo to pod sto. Četnost malých a maximálně velkých paketů je přibližně stejná (že by potvrzovací pakety, keepalive* a režijní informace?)

Otevřených TCP spojení je 36. Podle mě tohle všechno v žádném případě není nezvládnutelný provoz.

* Keepalive pakety jsou další důkaz o tom, že NAT způsobuje problémy. Kdyby všechny stroje byly přístupné z netu, nebylo by nic takového nutné - spojení mělo timeout? Nevadí, obě strany mají možnost ho založit znovu, pokud budou chtít.

[pavlix]

To bych zatraceně tvrdil. To už je podruhé, co se mě tu někdo snaží přesvědčovat o tom, že BT přenáší kdovíjaké veliké množství UDP paketů, přitom to *není pravda*.

Zajímavé, že mi ty UDP pakety vytvořily asi třikrát tolik záznamů v conntracku než TCP.

[Dan Ohnesorg]

Nevim jestli i v tomto pripade, ale TCP a UDP conntrack se lisi. U TCP totiz vim kdy zanika spojeni a tak ukoncene spojeni z conntrack tabulky mohu odstranit. U UDP to nevim, takze tam musim spojeni drzet az do nejakeho (dlouheho) timeoutu. Takze potom opticky muze byt conntrack ucpany UDP provozem, i kdyz prevlada TCP provoz.

Ale nejak ani na sitich s intenzivnim P2P provozem nepozoruji extra velky pocet UDP spojeni:

gate ~ # cat /proc/net/ip_conntrack | cut -f1 -d" " | sort | uniq -c 9 icmp 21128 tcp 755 udp 43 unknown

[Dan Ohnesorg]

Ups jsem si to v nahledu neprecetl, takze vysledek

9 icmp

21128 tcp

755 udp

43 unknown

[Luboš Doležel (Doli)]

Jinak samozřejmě bez DHT nemám problém.

[kralyk z abclinuxu]

Taky jedu bez DHT a v pohodě. Mám dokonce dojem že můj oblíbený tracker ani DHT nepovoluje ale tím si nejsem jist...

[pavlix]

Potom mi vysvětli, proč na 5GHz obvykle stejný problém neřeší.

[Käyttäjä 11133]

Protože lidi, kteří si kupují 5GHz tak nekoupí ten nejlevnější rádiovej šunt co jde Alespoň vetšinou.

[Grunt]

Potom mi vysvětli, proč na 5GHz obvykle stejný problém neřeší.

Řeší ale méně, jelikož 5GHz má větší paketovou propustnost a stíhá odesílat a tím se mu tak moc nezaplňují buffery. A navíc pokud má last-mile řešenou skrze 802.11b, tak to ty béčka pochytají(A tak to nejede jen na daném segmentu). Na médiu nezáleží. U 802.11b je to spíš souhra náhod(malá max. packetrate, mnoho lidí na jednu anténu, špatně nasměrované antény, zarušení to všechno zkombinované z neznalostí a leností a o zábavu je postaráno)

[pavlix]

Zní to rozumně. Díky.

[Kroko]

a hlavně předimenzovaný výkon, kdejaký de*l si hodí anténu jak kráva, napere tam výkon co jde a vůbec neřeší to, že ruší lidi v širokém okolí nehledě na to že porušuje předpisy ČTU atd.

[pavlix]

A někteří poskytovatelé v CZFree síti na bázi udělej si sám, že :). Levné připojení do netu, nějaké (většinou ne moc dobré) propojení v rámci CZF.

Například ve vršovicích nabízeli že zařízení připraví a nainstalují oni, ale měli pak vyšší měsíční cenu (ne jednorázový poplatek).

To člověka, který neví, co je dbi, dbm a podobně přímo tahne k tomu, aby vzal silnou anténu (jistota je jistota), šoupnul ji na střechu... a k tomu nějakej levnej kousek hw, na kterém buď neumí (nebo ani není možné) dostatečně stahnout výstupní výkon.

Ale mě spíš nadchnul nějaký vtipálek, co mi dokázal přepálit na šestym kanále mojí wifi uvnitř bytu :D.

[Ondrej 'SanTiago' Zajicek]

Řeší ale méně, jelikož 5GHz má větší paketovou propustnost

Presneji receno 802.11a (5 GHz) ma lepsi propustnost nez 802.11b (tradicni 2.4GHz). Propustnost 802.11a a 802.11g (novejsi 2.4 GHz) je za idealnich podminek vicemene stejna. Akorat na 2.4 GHz je toho ruseni mnohem vic. Ale na vesnicich v kopcovitem terenu funguje 802.11g celkem dobre.

[pavlix]

Vidíš, já si říkal, že je to s těma áčkama, béčkama a géčkama složitější.

Co znamené celkem dobře? Líp nebo hůř než 802.11a?

[Ondrej 'SanTiago' Zajicek]

Zhruba stejne jako 802.11a.

[pavlix]

Dík.

[Ondrej 'SanTiago' Zajicek]

tšina bittorrent programů se snaží naprosto bezostyšně zablokovat linku svými pakety, nejdejbože, když je to na 2.4GHz wifi

IMHO nejpravdepodobnejsi pricina podobnych zvesti o blokovani linky torrentem je kvuli tomu, ze linuxovy firmware mnoha wifi krabicek ma casto napevno zakompilovanou podporu conntrack a casto nastavenou na dost malou hodnotu (treba i 512). Pokud takovou krabicku nekdo pouzije jako wifi AP, tak pri nekolika torrentech snadno hrozi preplneni conntrack tabulky a linuxovy router se pri preplnene conntrack tabulce chova dost divne.

[pavlix]

Ale fuj... kdysi mi kvůli conntracku nešel x86 linux router. Ten určoval conntrack podle velikosti RAM (default), nastavil si 4096. Na nejmenovaného (už si na 100% nepamatuju a nechci kecat) bittorentího klienta to bylo málo.

linuxovy router se pri preplnene conntrack tabulce chova dost divne.

To mi povídej.

[Majklík]

Naopak, protipirátské unie by jen uvítali plošné nasazneí IPv6. Proč? Protože dneska je většina lidí za NATy, pod jednou veřejnou IP je klidně půlka okresu, maximálně je na piráta přesměrován jeden port. Takhle někoho dohledávat dá práci, pokud je ISP se statutem neveřejné služby, tak nemusí nic logovat, jejich snaha spolupráce s Policií i když mají papír od soudu je minimální (kdo by se také tomu divil), takže kdyby měl každý svůj veřejný blok, tak se stačí pomalu jen mrknout do RIPE.

Tohle vidím z pohledu protipirátských unií jako velké plus pro jejich činnost. Bohužel musím viděl i mínus. IPv6 specifikuje jako povinnou součást IPsec, sice v reálu to některé implementace nemají, ale je otázka času. A také se nám začíná i šířit i DNS SIG, dokonce i CZNIC začíná něco v tom duchu experimentovat. Pokud by došlo na to, že se mohutněji rozšíří IPsec komunikace na prakticky jakékoliv spojení na základě klíčů z DNS, tak jejich sledování bude horší, taktéž ISPéčkům se bude huře filtrovat provoz. Samozřejmě můžou IPsec potlačovat, ale používá se hodně i pro zcela legiimní věci a narazí. Pokud by na něj došlo masivněji, tak se nám opět trochu narovná pošramocená síťová neutralita upřednostňování na základě protokolů, což je hlavně plus pro uživatle a ke zlosti unií.

Pohled ISP na IPv6 má také svá specifika. Přeci jen NATovat pár tisíc klientů něco stojí, zdržuje to, jsou s tím komplikace, každou chvíli někdo otravuje, že chce přesměrovat port nebo něco nastavit, aby nějaký obskurní protokol fungoval (VPN klienti dokáží pěkně vydusit, pokud ISP má segmenty kolidující s koncovými body VPNka). Provozování NATu u ISP nese i právní úskalí. Dle naší legislativy ISP nenese odpovědnost za obsah přenášených dat, ale jen do okamžiku, dokud obsah komunikace nepozmění. A v případě NATu do toho občas šahá až na aplikační úroveň, aby některé věci fungovaly. Nerad bych narazil na magora, který by chtěl zkusit na základě toho mi hodit na hlavu spoluodpovědnsot za piráta. Další problém je, pokud jsem ISP se statusem veřejné služby, musím o klientech držet data, abych na žádost soudu k informaci o čase, IP adrese a cíle spojení určil o koho jde, pokud mají klienti veřejné IPčka, tak je to pohoda, jen si držím seznam kdo je kdo, jakou má IP a pro úlitbu vyhlášky ještě schovávám sumárně kolik dat apaketů nasosali za den (co den, to jedne řádek v DB na kleinta). V případ NATu musím schovávat informace o všech spojeních, která přes NAT prošla, abych pak poldy uspokojil a neriskoval, že mi pošlou na krk ČTU s jejim pokutovým sazebníkem. A je to opět práce navíc a dost dat (a to jen skladujeme 6 měsíců, až nám EU v rámci boje proti teroristům vnutí 3 roky, bude hůře). Samozřejmě jsou i negativa, ne všechno v infrastruktuře umí dobře IPv6, ani takový mikrotik není bez šmouhy, zatím komplikovanější shaping provozu, pokud se rozmůže IPsec, bude zase o trošku horší "spravedlivé" omezování klientů atd. Ale i tak se toho do budoucna nebojím.

Pohled uživatele má také své specifika, hlavně v ČR, kde smysluplného obsahu (a celkově i v EU) pro běžného spotřebitele moc není, takže je to zatím spíše pro early adopters, na kterých se to musí odladit. Nicmén pár přínosů by se našlo a doufám, že seriálek je nezapomene pořešit.

[pavlix]

Nechám se rád inspirovat... ať už z komentářů nebo přes mail/jabber (viz odkaz na kontakty v patičce).

[David Jaša]

..., takže kdyby měl každý svůj veřejný blok, tak se stačí pomalu jen mrknout do RIPE.

Většina podle mě bude používat blok od ISP stejně jako dnes.

[Käyttäjä 11133]

Ano máš pravdu. Bude to stejně jako to dneska dělají ISP.

[Majklík]

Ano, obvykle by to mělo být tak, že ISP bude mít svůj IPv6 blok /32 a měl by přidělovat z něj bloky /48 na koncové klienty. Tyto bloky by měly být asi uvedeny v RIPE DB samostatně s identifikací jejich uživatele. V případě IPv4 je to stejné, obvykle máme IPčka od ISP (pokud nemám teda PI blok, vlastní ASko atd) a ISP by měl IP delegované na koncového klienta uvést do RIPE DB s příslušnými informacemi. Přesněji nemusí rozepisovat v případě, že přiděluje bloky s maskou /30, kdy ta čtyřípečková síť je spojovací k zákazníkovi a ten má z toho reálně v používání jen jednu IP, v takovém případě ho do DB uvádět nemusí pro ochanu jeho soukromí, pokud ale zákazník dostane k používání větší blok, tak by měl být už v RIPE DB uveden. Jiná věc je, že na to řada ISP kašle a nedělám si iluze, že nebude kašlat i u IPv6.

Ale i tka se shodnem, pokud nafasuje každý zákazník svůj veřejný IPv6 blok, tak dá antipirátům míň práce dohledat jeho uživatele i ISP se bude moc o trošku hůře kroutit, že neví kdo to je (pokud nebude přidělovat IPčka přes DHCPv6, autokonfiguraci, atd).

[b*d]

Vetsina tady resi odstraneni NAT/maskarada v domacich / firemnich sitich ze strany klienta, ale to neni ten zasadni problem, co zene ipv6 dopredu.

Dle meho nazoru je problem na strane poskytovatelu:

napr. ICQ musi mit nejaky server, ktery jenom kopiruje soubor pokud si ho uzivatele chteji poslat (pac se nevidi)

virtual host je dalsi berlicka, jak obejit nedostatek IPv4 adres, diky tomu je HTTPS pomerne nakladne (vlastni IP -> min virtualni server)

virtualizace - cena energie roste, produkce tepla stoupa, misto pro serverovny dochazi - jako dobre reseni je vysoce redudantni server pro x sluzeb oddelene virtualizaci.

Vesmes vsechny message driven aplikace jsou z nemoznosti plne komunikovat tam i zpet zkrypleny, nemusi byt efektivni a zbytecne zerou proud a kapacitu.

[Michal Kubeček]

napr. ICQ musi mit nejaky server, ktery jenom kopiruje soubor pokud si ho uzivatele chteji poslat (pac se nevidi)

Jenže důvod, proč ICQ (a nejen ICQ) vypadá tak, jak vypadá, je z velké části právě v těch maškarádách. Kdyby nebyly maškarády, mohlo by to fungovat podobně jako třeba SIP, tj. server jen pro navázání kontaktu a vlastní komunikace přímo.

[b*d]

jo jo - ja to myslel tak, ze to prodrazuje poskytovani sluzby, tedy ne z pohledu klienta. Tim padem klient musi zaplatit vice, at uz primo nebo neprimo pres reklamu atp.

[mmrnda]

Tak mě napadají dvě otázky.

1. Co když i tento rozsah bude brzy malý? Mobil, PC, tiskárna a bůhvíco ještě si každý v budoucnu připojí k internetu. ;)

2. Celkem mě z bezpečnostního hlediska zaujala věc, že paket má podle článku „Také samozřejmě odpadá délka hlavičky a místo pole Protocol se používá Next Header, které navíc umožňuje vkládat rozšiřující hlavičky (náhrada za options).“ Next Header. Nebude se dát náhoudou tato hlavička snadněji podvrhnout?

[pavlix]

Jsem rád, že se můj článek stále ještě čte :).

ad 1. Tahle situace nepřipadá v úvahu při dnešním pohledu na síťování a internet. Přesto velikost adresy není jediné opatření, které spolu s protokolem IPv6 přichází.

A co víc, s něčím takovým se nepočítá ani při přidělování EUI identifikátorů (neboli mac adres). Rozsah EUI se zvětšil z 2^48 na 2^64. Stačí trošku počítat a člověk zjistí, že z dnešního pohledu je rozsah IPv6 adres je daleko více naddimenzovaný než byl ve své době rozsah IPv4, který své tehdejší cíle řádově přesáhl.

Nevidím smysl dnes plánovat rozšíření internetu na okolní mimozemské civilizace :). Až to přijde, tak se bude řešit :D.

ad 2. Má tento dotaz nějaký skrytý reálný základ? Pokud vím tak vygenerovat paket podle mých představ lze úplně stejně jednoduše bez ohledu na protokol (pokud vím, co v tom paketu chci mít).