Vlákno názorů k článku IPv4 adresy definitivně došly a další nebudou od Kolemjdoucí - IPv6 se prosadí až tehdy, až koncoví zákazníci...

Nu, jen popisuji zkušenost ze sítě ISPíka okresního formátu, kde se v nabídkách i na webu taktně mlčí o tom, zda veřejná/neveřejná IPv4/IPv6.
Pokud se lidi aktivně zajímali, tak spíše v tom, že chtějí být za NATem, než s požadavkem na veřejku (ta se dfává zdarma na žádost za asi 300 Kč jnorázový poplatek). Jako zdůvodnění, když se člověk ptal, tak to co jsme uvedl o dohledatelnosti.
Torrent jed ei za tím blbým NATem, pokud ne, tka je spíše na vině dneska snaha ISPíka prznit a utlačovat torrent jako takový nejrůzněšjšíma nesmyslama v řezání rychlostí atd.

Torrent za NATem nefunguje, funguje v pasivnim rezimu => nede se sosat od vsech se stejnou chorobou. A presne jako chorobu je treba NAT vymytit.

Pokud si nejakej mamlas mysli, ze je za NATem nedohledatenej, tak to maximalne svedci o jeho IQ houpaciho kone. Pokud chci bejt (realtivne) v bezpeci, koupim si VPS na predplacenou kartu nekde ve Svycarsku.

Tak tohle snad záleží i na druhu NATu a čím je aplikován, V kombinaci s Torentem, pokud jede µTP protokol (nad UDP) a použije se STUN, tak celkem OK to prolézá. S TCP je problém, tak tam NAT traversal je na tom mnohem hůře a přes některé není šanci (např přes FreeBSD PF). Druhá věc je, jak jsou na tom klienti s implementací těchto volovin (µTP). Nicméně se tohle obvkyle řeší, ze zákazník fasuje blok portů, který se na něj forwarduje a s tím němá Torrent nejmenší problém.
Jistě, s IPv4 veřejkama až na router zákoše je život jednodušší (a ten home NAT pořeší UPnP), ale život není ideání... :-)
Onoani s IPv6, co jsem si všiml, zaítm řada Torrent klientů moc nefungovala OK.

Argument nebyl tak vysledování aktuálně, to samozřejmě jde, ale to zpětné dohledání. U NATu jde po omezenou dobu, co mám netflow 6 měsíců (a pokud bych ukládal data jen striktně dle požadavku vyhlášky, tak to občas ani dohledat nejde). Ale pokud má svoji veřejku, dokážu ho identifikovat roky zpětně velice snadno...

"Ale pokud má svoji veřejku, dokážu ho identifikovat roky zpětně velice snadno...
"

Jakto? Tam je legalne mozne uchovavat vic nez 6 mesicu smirovacich dat?

Pokud jsou dva torrenťáci oba za různým NATem, tak si mezi stáhnou kulové. Může se to vysvětlovat 10 let a stejně je to marné.

A aktivní klient s veřejnou IP tedy od pasivního klienta (za NATem) stahovat může jo?

Super díky za vysvětlení. Já si právě říkal, jak je tohle možné, když já jsem za NATem a normálně lidi se ke mě na P2P připojí a stahují od mne. A ještě zajímavější je to, že to funguje automaticky, tzn. nic jsem na klientovi nemusel nastavovat a ono to funguje. No nic, díky za objasnění. :)

Ad domlouvani se pres verejny server: vsechny P2P site, ktere se autokonfiguruji (skype, torrent, ...), potrebuji prostrednika, pres ktereho si ty aplikace sdeli ze jsou online, a co poskytuji za sluzby (V pripade torrentu je to tracker). Pokud mam nat, na kterem se da "otevrit UDP port", tak mne muze kdokoli kontaktovat (aktualni cislo toho UDP portu vystavim na tom trackeru). To jsou naty ktere port na vnejsi ip adrese mapuji na port+adresu na vnitrni siti bez ohledu na adresu opacneho konce spojeni. Nektere "chytrejsi" naty klidne prideli spojenim ktere se lisi pouze vzdalenou adresou/portem ruzne vnejsi porty i kdyz vnitrni adresa/port je stejna, pak je to teprve tak jak tu tvrdite, ale rozhodne se tak vsechny naty nechovaji (ono to muze zamezit fungovani nekterych obskurnich UDP aplikaci).

P.S. spojenim zde myslim i "nespojovanou" komunikaci po UDP mezi dvema aplikacemi.

Ono to záleží na tom, jaký protokol Torerent klient podporuje, pokud už umí uTP s UDP, tak to funguje trošku jinak, kde to UDP s esnaží i obejít limitace na TCP ohledn řízení propustnosti.
uTP protokol nad UDP umí i přímou komunikaci mezi dvěmi koncovými stanicemi, co jsou za NATem, ten prostředník se použije jen k počátečnímu domluvneí a proražení UDP portů ven na obou stranách a pak už se posílají data přímo. Podmínka je, že když už je použit CGN NAT, tka nesmí být dementní, aby prostřeník v roli STUN nedokázal určit vnější porty, co se použijí pro P2P komunikaci.
Takže ano, koncák za NATem si drží otevřené spojení na tracker, kde čaká, zda někdo o něco požádá a až jop a pokud oba umí uTP, tak proveodu pomocí STUN otevření UDP portů na svých NATech a data pak tečou přímou mezi nima (pokud jsou na obou stranách rozumné typy NATů - ne symetrický a randomizující).

Ohledně toho zpětného dohledání - za NATem je víc chráněn. Pokud má zákazník svoji veřejku, tak dokáži na dotaz soudu identifikovat některé 5 i 8 let zpětně (občas jde dotaz od soudu i rok zpětně). Pokud je zákazník za NATem, tak držím informaci jen 6 měsíců, na starší odpověď je sorry NAT, smazáno.
Od soudu nepřijde žádost, vypište mi spojení a kam se spojval někdo, protože aktuální prováděcí vyhláška toto neumožňuje. Já mám jen u sebe držet informace o stavu NATu, to jest v jaký čas, jaká vnitřní IP adresa:zákazník na co byl NATován na veřejnou IP:port:protokol, ale už ne informaci o tom, kam šlo spojení! (Pomiňme, že pokud něco už korektně sbírá netflow z NATu, tak to uládá i cíl). Takže přijde požadavke, kdo měv v čase X, IP adresu Y? Je to věřejka koncáká, předávám, je to NAT - sorry, NAT, půlka okresu, dojde upřesnění čas X:Y:Z až X:Y:Z.zzz,IP Xm port P, protokol Q. Pokud dle toho dohledám, kdo měl spojení z této kombinace, tak prásknu, ale může se stát, že i tak to odpovídá víero lidem a odpovídám - sorry, cca 5 lidí. Bez informace o tom, kam to spojení šlo to nejde jendoznačně určit a tuto informaci o cíli spoejní já (správně) ukládat nemám. Proto soud nemůže žádat o seznam spojení a ani to aktuálně nedělá, protože je správně nemám mít uloženy...
Je nyní požadavek Bezpečnostní rady státu, aby ISP měl povinnost ukládat i adresu:port kam spojení šlo (což fakticky dělají často už teď v netflow datech), pak teprve půjde jednoznačně vždy dohledávat lidi. Ten návrh současného evidentně dělal někdo, kdo nepočítal s NATy, co pro každé spojení neotvírají nový port.

> Ohledně toho zpětného dohledání - za NATem je víc chráněn.

Můžeš je dát do jedné /64 a použít privacy extensions.

Tohle jsem úplně nepochopil?

Jako ISPík dávám IPv6 segment na zákazníka, domácnost dostane /60, já si jen vedu, kdo má jakou /60 přidělenou. Co si s tím doma dělá je mi fuk, Klidně ať použije privacy extensions, aby měl IPv6 adresu na konci náhodnou, to mi je jendo.
Při požadavku na identifikaci já hledám jen dle toho /60 prefixu a sdělím na koho je daná smlouva/přípojka, co se dělo tam, to mi je zcela fuk....

Pokud jsi to navrhoval tak, že mám třeba panelák s 50-ti byty a přípojkami, s koro každým mám smlouvu a schovám je tak, že dám všechny jejich přípojky do jednoho L2 segmentu a na něj pustím jednu /64, tak si já jako ISPík život komplikuji, protože koncový bod sítě je ta přípojka na bytě a já pak budu muset sbírat jednotlivé linky a vést si seznam jaké IPv6 adresy na jakém portu byly a dle toho pak dohledám o koho šlo. Což je zbytečná práce navíc. Protože jaksi pokud v tomto případě řeknu, sorry, je to panelák, co má jendu /64 a v něm je 40 přípojek, tak se soud také může naštvat, podat stížnost k ČTU a můžu mít na krku správní delikt v neplnění požadavku zákona s pokoutou 5 MKč. Navíc z takového je spousta komplikací, kdy buď se musí ty byty vzáájemně vidět v jedom segmentu a polezou si tam nebo udělám izolaci portů a sousedi k sobě pak nemůžou vůbec, pak leda to dát jako offlink adresy, aby to šlo skrz router a tam firewall, to zase způsobí i lokální domácí provz skrz router, ....
Takže do tohodle jao ISP nepůjdu.

Jiná je, když je ten panelák třeba bytové družstvo a družstvo si objedná přípojku na barák, já končím na patě baráku jednou veřejkou a blokem /56, co jim předám, tam ať si s tím udělají, co chtějí.... Při požadavku na indetifikaci mám smlouvu s družstvem na předávací bod a udávám jako majitele přípojky družstvo, ať si dál s tím naloží vyšetřovatel jak chce, já si své splnil.

> Při požadavku na identifikaci já hledám jen dle toho /60 prefixu a sdělím na koho je daná smlouva/přípojka, co se dělo tam, to mi je zcela fuk....

No a ten prefix můžeš po půl roce „zapomenout“ stejně jako dneska po půl roce zapomínáš seznam přeložených spojení na NATu.

> protože koncový bod sítě je ta přípojka na bytě a já pak budu muset sbírat jednotlivé linky a vést si seznam jaké IPv6 adresy na jakém portu byly a dle toho pak dohledám o koho šlo. Což je zbytečná práce navíc.

No ale to teď když je máš za NATem musíš dělat ještě víc (nestačí ti trackovat IP adresy, ale musíš ukládat všechna překládaná spojení).

> Navíc z takového je spousta komplikací, kdy buď se musí ty byty vzáájemně vidět v jedom segmentu a polezou si tam nebo udělám izolaci portů a sousedi k sobě pak nemůžou vůbec

Jak tohle řešíš když máš ten panelák za NATem? Tam na sebe v té privátní síti taky vidí, ne?

> No a ten prefix můžeš po půl roce „zapomenout“ stejně jako dneska po půl roce zapomínáš seznam přeložených spojení na NATu.

Legislativa je tak, že informac,e co zbírám primárně za účelem vyhovění data retention, tak ty musím po 6-ti měsících mazat, což snad i všichni činí. Informace, co vznikají a udržuji primárně z jiných důvodů, ty si mohu držet jak dlouho potřebuji, takže pokud mají zákazníci veřejné adresy IPv4 i IPv6 bloky roky, tak za tyto roky zpětně dokážu odpovědeť na idnetifikační požadavek a odpovídá se (reálně se nešlo zpětně dál, jak rok). Protože tak to po mě žádá i obecná legislativa.
Nehodlám koncáky krýt a vystavovat sebe riziku, za těch pár korun od nich mi to nestojí. Nemám zájem na sebe poštvat ČTU na téma auditu mých systémů a podobných vylomenin, protože tohle krytí se dá relativně snadno odhalit...

> No ale to teď když je máš za NATem musíš dělat ještě víc (nestačí ti trackovat IP adresy, ale musíš ukládat všechna překládaná spojení).

Ano, pro lidi za CGN musím ukladat stav NATu. A proto nehodlám si prznit konfiguraci IPv6 tak, abych musel ukládat podobné ptákoviny, když se jich chci zbavit. A už vůbec ne jen proto, abych tím kryl identitu koncáků....

> Jak tohle řešíš když máš ten panelák za NATem? Tam na sebe v té privátní síti taky vidí, ne?

Provozuji snad přístupovou síť k Internetu a ne LAN pro panelák. Klienti se samozřejmě přímo nevidí. Je aplikována izolace portů od sebe. Spojit se na sebe mohou, ale jde to přes L3 prvek a trochu delší cestou než jen dva sousendí porty mezi sebou na tom switchi v baráku. Ať mají IPv4 veřejky nebo neveřejky, či IPv6, je to stejné. A už vůbec proto nebudu síť přestavovat na barákové L2 segmenty.
(Někdo to tak má, že panelák je jeden L2 segment a lidi se vzájemně vidí, je víc metod, jak to dělat, záleží na použité technologii a co jak chci dělat. A někdo izoluje natvrdo, že se sousedi na sebe vůbec nemohou přímo spojit.)

ja myslim, ze to ten kriplikup vysvetlujete marne. nepochopi...

Jestli je někdo pitomec, pak jste to vy. Za NATem je člověk anonymní z toho pohledu že nelze (bez specifické znalosti protokolu) obecně říci, KTERÝ počítač za NATem v tom daném momentě komunikuje, resp. ani to, KOLIK těch zařízení za NATem vůbec je...

Jde to asi tak stejně „špatně“ jako s privacy extensions. Tedy není to úplně jednoduché, ale lze to docela dobře odhadovat.