Vlákno názorů k článku IPv6 Mýty a skutečnost, díl IV. - Podpora autokonfigurace od davro - už se o tom rozhodlo a vy se...

už se o tom rozhodlo a vy se můžete tak maximálně přizpůsobit.

Nebo si napsat vlastni software, ktery bude mit jiny nazor...

Komu by to k čemu bylo? Facebook dlouhodobě poběží na IPv4 tak jak tak, stejně jako většina důležitých služeb (kdyby ne tak jejích provozovatelé můžou zrovna zavřít krám a jít na pracák). V takovém případě poskytovatel udělá raději 3 NATy za sebou, než by šel do IPv6 (protože jinak by také mohl jít rovnou na pracák).

Navíc při konverzi IPv4 na IPv6 musíte řešit konverzi DNS z AAAA na A, ale to jsou věci technické takže snad i řešitelné.

Popravdě řečeno v podobné konfiguraci mám problémy spíše s mobilními klienty, kteří jsou připojeni různě přes IPv4, jak nejrůznější NATy se snaží intelignetně strkat pracky kam nemají, hlavně do VPN protokolů pro road-warriors. Je vtipné pozorovat, jak někde funguje PPTP, jinde zase jen IPsec, někde ani jedno. Jindy je síť, kde neprojde HTTPS (takže i SSTP je nepoužitelné), ale IPsec bez problémů. Jsou místa, kde z jednoho notebooku funguje PPTP, ale vedle připojený, prakticky identický notebook se nespojí, ten projde zase přes IPsec, ....
Podobně vesele se chová kolikrát SIPový VoIP, pokud klient má být mobilní a připojovat se přes růzé sítě (někde to NAT zprzní, někde ne, jednou je dostupný venkovní STUN, pak zase není, tak to některé položí a klient musí mít několik konfigurací podle toho, kde právě je).

Hmm, "moje" firmicka s par stovkami IP zarizeni ma (mimo jine) IPv6 a vpohode to funguje. Nikde zadny problem.

Na IPv4 maj vsici vsechno zakazany prave kvuli tomu podelanymu NATu. Kdyz maj jednu IPv4 adresu, tak se bojej, ze se dostane na blacklisty pokud jim tam nekdo prinese zacervenej stroj.

Pokud budu mi desitky prefixu IPv6, tak jednoduse jeden vyclenim pro anonymne dostupnou sit (napr v hotelu) a bude mi naprosto sumafuk co tam kdo dela.

Ano, tuto úvahu také uvádím. Nepředpokládám, že to bude zcela bez firewallu a otevřeno všechno všem, to by blyo asi brzo pěkné semeniště. Ale je možné, že bude méně restriktivní, než současný stav. Přeci jen asi až dojde na strkání do blacklistů IPv6 prefixů, tka je otázka, zda blecklistaři budou strkat /64, pak takový guest segment je pro firmu relativně v pohodě nebo natvrdo bude strkat /48, což už by nebylo dobře (nebo inteligentně v DB hledat, do jakého segmentu daná IPv6 patří a ten blacknout celý, což by tkaé firmu nepotěšilo, případně celého ISP, pokud nemá publikovanou delegaci).
Samozřejmě asi pro krytí zad to bude chtít nějaký monitoring a logging, už jen kvůli případné buzeraci od státních ouřadů - jaká mac byla kdy připojena a s jakou veřejnou IP šla ven (takže pro nejmenší jednoduchost třeba firewall nedovolující privacy extensions a k tomu by byl fajn třeba příznak do RA nebo DHCPv6, že klient nemá používat PE a podobné).

Na IPv4 maj vsici vsechno zakazany prave kvuli tomu podelanymu NATu.

To rozhodně není pravda. Jednak je možné, že na IPv6 se bude blacklistovat celý /48 segment.

A dále co mám zkušenost, tak restriktivní firewall pro příchozí spojení se používá např.: a) kvůli bezpečnosti (viry na windows), b) kvůli omezení p2p sharing sítí. Omezení odchozích portů na 80 a 443, někdy 21 apod. je také velmi efektivní nástroj k zamezení přetížení linky p2p aplikacemi. Ano, není to dokonalé, lze nasadit nějaký l7filter, ale zatím to funguje víc než dost.

Podle mě tedy IPv6 administrátorlm důvod k volnějšímu nastavení firewallů nepřinese.

Nebude, protoze tech prefixu je vic nez IPv4 jednotlive.

a) v siti kam se pripojuji anonymni stroje, je mi jejich bezpecnost uprdele, at se staraji jejich uzivatele.
b) to je mi taktez ... jednoduse vyclenim nejake pasmo, nastavim rozdeleni 1:1 na IP a vyrizeno, nejaky L7 mi muze ... (resit provoz na L7 muze i na v4 opravdu jenom magor)

Specielne kvuli buzeraci od uradu je treba nelogovat vubec nic. Celkem by me zajimalo, jak na firewallu zakazete privacy extension ... ;D, bavime se stale o anonymne pristupnych sitich, ze ? Tedy hotely, restaurace ....

a) v siti kam se pripojuji anonymni stroje, je mi jejich bezpecnost uprdele, at se staraji jejich uzivatele.

Vám možná ano, obecně to neplatí. Však výchozí blokování příchozích spojení na SOHO zařízeních doporučuje i jeden RFC. Ono vám pak budou chodit abuse reporty na ten "anonymní" segment. Je lepší se tomu vyhnout.

b) to je mi taktez ... jednoduse vyclenim nejake pasmo, nastavim rozdeleni 1:1 na IP a vyrizeno, nejaky L7 mi muze ... (resit provoz na L7 muze i na v4 opravdu jenom magor)

Jednak shaping fair-per-ip pro dynamický počet klientů není a nebude úplně standardní funkce v základních zařízeních - tak standardní jako prostý filtr na bázi portů. A i tak, L7 shaping není blbost. Záleží na situaci. Ale jsou sítě kde i při fair-per-ip shapingu pár uživatelů s torrentem vyvolá "nespravedlivou" situaci -- rozumějte že kdyby se všichni omezili na běžné používání a nestahovali na p2p, tak by ostatní měli mnohem rychlejší linku, hlavně subjektivně při načítání webů apod. Takže pak se hodí mít možnost veškeré P2P na L7 odfiltrovat do nejnižší priority. Dnes už to není tak akutní, páteřní konektivita je celkem levná a dostupná, ale pár let zpět tohle řešil každý druhý WiFi ISP.

A to opomíjím fakt, že zrovna v oblasti QoS je problém, že v Linuxu (a i v MK RouterOS) nejde do jedné fronty dávat společně pakety v4 i v6. Tj. nelze jednoduše např. konkrétnímu klientovi vyčlenit 2 Mb/s dohromady pro v4 a v6.

Nic se nerozhodlo, zatím to vypadá, že existuje moře cest, ale trhu se nechce ani do jedné. Jediné, co tedy zatím umíme je IPv6 směrovat. Dostat ji až ke koncovým zákazníkům a do vnitřních sítí je problém. Zatímc se IPv6 tedy dá používat jen přes tunely a teredo, nedokážu si představit, že bych na IPv6 postavil celou vnitřní síť.

evidentně nemáte pravdu. Já žádný tunel nepoužívám. A naše tiskárna chce jako na sviňu používat IPv6 a skoro jsme ji nedonutili k IPv4.

Jistě, něco to nevyřeší (kde má někdo totálně restriktivní firewall, tak ho bude mít ais i na IPv6). ale problémy, kde mi do toho kecá NAT, by IPv6 v současném stavu pomohlo, ať už situace, že mám dva cesťaky někde spolu a oni současně se zkusí připojit na firemní PPTP a když pro to nemá NAT spešl podporu, tak si to vzájemně budou shazovat, stejně tak zas,e pokud půjdou přes IPsec, tak pokud NAT do toho bude aktivně hrabat, tak se spíše nespojí, další kapitolou je SIP ALG v NATech atd, takže tuto třídu problému IPv6 odstraní, pokud koncák dostane globální adresu.
Jistě je zajimavá otázka, jak se protokoly vyrovnají s variantou, která bude určitě také oblíbená, že bude v síti ULA a aplikaovaný překlad prefixů, takový IPsec by z toho v aktuálním stavu nemusel být nadšen (a nejsem si jist, že NAT-T rozšíření počítá s něčím takovým).
A myslím, že by částečně i IPv6 mohlo pomoci, aby někteří paranoici neměli tka restriktivní firewall, když budou mít dost adres, aby méně důvěryhodnou komunikaci návštěvníků vystrčili na samostatný prefix, místo součansého NATování na jendu adresu s celou firmou.
Nejsem nadšený propagátor IPv6, ale realista, který má dneska pod seobu road-warriors, kteří v cílovém místě pobytu překvapivě hlásí, že je k mání jen IPv6 konektivita a ať se něco udělá a dostaonu se do firmy k mailům, souborům, ... (zase to vypadá, že z Číny snad IPv6 konektivitu ani nefultrují, asi soudruzi usoudili, že IPv6 obsahu je tak málo, že se s ním zatím nemusí párat). Takže nezbývá než se se současným stavem vyrovnat a popasovat i když k některým věcem mám také výhrady.
Co se týká toho přidělení globální adresy, tak s ním jsem celkem srovnán. Ano, u RA byl dlouho problém to DNS, specifikaci to dneska má, podporu v reálném HW/SW zatím mizivou, to se asi napraví časem. Mám i aplikaci, kde se aktivně využívá toho (zaítm experimentálně), že dva routery do sítě dávají své prefixy (s relativně krátkým lifetimeme) a když jednomu chcípne konektivita, tak se přestane propagovat a jde to druhým segmentem. V IPv4 na to používám VRRP, ten je i rychlejší při výpadku než přepínání dle RA, ale VRRP jde nasadit iv IPv6 a v kombinaci s ULA/překlad prefixů bude zajimavý. Takže proto třeba i chápu, proč nepočítali s default routou v DHCPv6. Zase takové DUID místo klasické MAC už nadšení nesdílím po zjištění, že některé "IPv6 ready" krabičky s podporou DHCPv6 se chovají tak, že po každém zapnutí si vygenerují DUID nový, jak je právě napadne. Ale tady předpokládám, že implentátoři DHCPv6 serverů budou mít pochopení a půjde to nastavovat dle MAC. :-) A takto by šlo pokračovat.
Berme to, že IPv6 je stále nováček. IPv4 je tady 2x tak dlouho a kus a také trvlao dost dlouho, než si řada věcí sedla.
Jsem už mezeální kousek, takže pamatuji to prskání s přechodem na clasless routování a kolik problémů nadělalo toto v síti. I když z dálky jde o celkem nevinnou věc a neměl by být problém, aby si routery jdoucí podle tříd vedle těch maskových nějakou dobu vyžili.... Také to nebyla pravda (jak jsem si i sám experimentálně před skoro dvaceti lety ověřil při složení půlky Evropy). A případné současné upradování IPv4 by dneska na tom bylo asi dost podobně. :-( Takže nezbývý, než se vycvičit pro IPv6 a být připraven na tvrdý dopad reality. :-)

p2p JE standardni vyuziti linky, jde dokonce o nejzadanejsi sluzbu vubec, takze o tom nema vubec smysl diskutovat. Naopak, 99,9% zarizeni neumi cokoli na L7, je to vypocetne narocne a stejne to neni nijak zvlast pouzitelne, navic to muze narazit na pravni potize.

A to ze neco neumite neznamena ze to nejde, zrovna QoS specielne v Linuxu umi uplne vpohode definovat spolecnou rychlost pro IPv4 a 6 dohromady. Pouzivam to nekolik let.

Díky za články, tohle jsem opravdu nevěděl. Zdá se, že IPv6 má víc problémů, než přínosů. Proč zase někdo už po několikátý vynalézá kolo?

(a přitom by stačilo do DHCPv6 přidat výchozí bránu a celý problém s autokonfigurací je vyřešen)

Kdo to rozhodne? Nějaký genius? Nebo o tom necháme hlasovat? Evropská unie? Nebo Obama?

Čověče, tobě bych teda fakt svěřil síť. Chudáci zákazníci, co u nich "adminuješ".