IPv6? A k čemu prosím vás?

5.5.2010 11:33 | Přečteno: 3586×

Adresní prostor IPv4 se jednoho dne vyčerpá o tom nemá cenu diskutovat. IPv6 ale jakoby nikdo nechtěl - protože existují řešení pro záchranu v4. Nikoliv technický, ale stěžovací zápisek.

Odkud začít. Doma jsem řešil problémy s připojením, které asi nemá smysl dlouze popisovat (prakticky se jednalo o port forward na 3 stroje a stejnou službu). Naštěstí mám inteligentního ISP (je sice hezké mít na chodbě vlákno, jenže od jeho vlastníka, firmy RioMedia, se dozvím akorát tak seznam TV stanic a rychlost připojení sice pěknou, ale bez IP konektivity jaksi zcela zbytečnou) se kterým se dobře spolupracuje, takže problém byl vyřešen přidělením IPv4 /29 subnetu což pro mě zatím stačí a až tam budeme dva, tak už snad budu mít IPv6 /48. Takto to má vypadat. Chceš IP? Dostaneš.

Teď ty problémy. Jistému nejmenovanému (protože je to jedno) úřadu státní správy docházejí v4 adresy. Spravuji pro ně dva servery a už při instalaci druhého byl problém s volnými IP. Jeden by si myslel, že to bude impuls pro nasazení (nebo alespoň uvažování o nasazení) v6. Nikoliv. Řeší to překladem 1:1. Je přece fajn mít z každé strany jinou IP pro tentýž server. Tak co, vyřeší se to vnitřním a vnějším DNS serverem - dotaz na stejné jméno vrátí jinou IP podle toho, zda jste venku nebo vevnitř. Krása. A nařízení vlády o použití IPv6 pro nové servery? Však on to možná po volbách někdo změní a když ne tak je to jen další věc, která se nestihla.

Další krásný nápad je http proxy 6to4. To je prosím navrhované řešení jednoho známého v diskusi na téma IPv6. Ono s tím souvisí i snahy některých sledovat a filtrovat http provoz no a když už tam ty proxi jednou budou...

Jako třešničku na pomyslném dortu beru preferenci natu jednoho dalšího známého. Jeho tabulky filter, nat a mangle, queue tree-shaper v RouterOS bych vám tedy nepřál. Totéž by se na routovatelných adresách udělalo několika srozumitelnými pravidly. Jenže nat je bezpečný, že jo. Co na tom, že to pravidlo v tabulce forward -i WAN -o LAN -j REJECT nemá s překladem adres pranic společného.

Takže asi tak. IPv6 není potřeba. Na vše je řešení, 65535 počítačů doma má málokdo a těch pár počítačů je i z jedné adresy krásně dostupných.

Co mi již delší dobu vrtá hlavou je proč tito (a to prosím nejsou žádné IT lamy, jedná se o programátory, správce sítě a v jednom případě dokonce i šéfa IT oddělení) lidé odmítají IPv6. Proč nechtějí globální dostupnost svých strojů (z hlediska triviálního routování) s jasně danými adresami a místo toho vymýšlejí řešení jak obejít problémy, které by vůbec nemuseli mít.

       

Komentáře

[Jirka]

Co mi již delší dobu vrtá hlavou je proč tito (a to prosím nejsou žádné IT lamy, jedná se o programátory, správce sítě a v jednom případě dokonce i šéfa IT oddělení) lidé odmítají IPv6. Proč nechtějí globální dostupnost svých strojů (z hlediska triviálního routování) s jasně danými adresami a místo toho vymýšlejí řešení jak obejít problémy, které by vůbec nemuseli mít.

Tak nad tím taky přemýšlím. Chápu, že některé implementace IPv6 mohou v některých zařízeních a sítích přinášet problémy (a tudíž velké finanční náklady na přechod, které si žádný manager nevezme na triko), ale IMHO výhody IPv6 přebijí snad všechno. Já se třeba nemůžu dočkat doby, kdy budu zcela běžně používat IPv6 Mobility.

[pasmen]

Já teda o IPv6 vím hodně málo, takže to možná nebude mít dostatečnou váhu, ale... Chápu, že třeba přechod páteřního routeru z IPv4 na IPv6 je celkem v pohodě. Stačí mít ISP, který IPv6 konektivitu má. Pak se akorát přenastaví vnější rozhraní a je to. Ale neumím si moc dobře představit přechod LAN z IPv4 na IPv6. Nehledě na to, že těch LAN máme 6 (propojené přes IPsec, čehož by se změna týkala pouze změnou rozhraní těch hraničních routerů a změnou tunelů). Teď je to pohoda, člověk zná IP adresu každého serveru nazpamět, cca 30 strojů. Představa, že se z těch hezkých adres stane kurník, to by znamenalo minimálně zavedení DNS. Tudíž, pro mě osobně přechod na IPv6 v LAN pražádnou výhodu nepřináší, naopak. Tam mi IP adresy nikdy nedojdou. A pokud bych měl řešit přechod na routeru, pak jde o jeden (no vlastně tak pět...) strojů, ale tam je mi to zase skoro buřt když už IP adresu máme. A směrovat na více strojů dovnitř netřeba, vždyť máme VPN! Takže tak, toť pohled někoho kdo ví o IPv6 hodně málo Ale v tomhle asi úplně sám nebudu.

[Heron]

Co přesně ti brání zbavit se na vnitřní síti těch vnitřních adres a použít tam globální? Tomuhle právě nerozumím. Pokud tam chceš udělat přístup teď, musíš řešit nějaký překlad na veřejnou atd. Pokud by jsi tam měl globální adresy, tak jednoduše povolíš danou adresu ve forwardu.

Teď je to pohoda, člověk zná IP adresu každého serveru nazpamět, cca 30 strojů. Představa, že se z těch hezkých adres stane kurník, to by znamenalo minimálně zavedení DNS.

Pominu-li, že IPv6 může být díky '::' krásné krátká (/48 prefix::1, ::2 apod.) tak nasazení DNS je prospěšné i pro IPv4 sít. Pak si netřeba pamatovat jakékoliv IP a ty se mohou snadno změnit (změnou na DHCP).

A směrovat na více strojů dovnitř netřeba, vždyť máme VPN!

Jo, to jsem v zápisku taky zapomněl. Globální routování netřeba, máme tunely.

[pavlix]

A když nechcem serverové DNS, tak proč nepoužít multicast DNS (mDNS), že, případně nějakou alternativu.

[pasmen]

Tu první část jsem moc nepochopil, ale to bude mou neznalostí. Ale přece, zkusme to z opačné strany. Co mi přinese přechod na IPv6? To je úplně základní dotaz, který si asi bude pokládat každý. Mám tolik IPv4 adres, kolik potřebuji, tudíž mě nějaké vyčerpání netankuje.

[Heron]

Co mi přinese přechod na IPv6?

Možnost globálního adresování všech tvých strojů.

Mám tolik IPv4 adres, kolik potřebuji, tudíž mě nějaké vyčerpání netankuje.

Pokud máš IPv4 /16 tak gratuluji. Ale IPv6 konektivitu budeš časem také potřebovat už jen pro připojení na servery s IPv6 (a bez 4).

[Ondrej 'SanTiago' Zajicek]

Ale IPv6 konektivitu budeš časem také potřebovat už jen pro připojení na servery s IPv6 (a bez 4).

Pokud takove budou.

[Käyttäjä 11133]

Už dneska takové jsou.

[pasmen]

K čemu potřebuji globální adresování svých strojů? Já ani nechci, aby byl každý z těch strojů vidět napřímo. Tím nemyslím že nebudu mít firewall, ale i tak. A abych se připojil k serverům co mají pouze IPv6 snad já IPv6 nepotřebuji, stačí mi, když IPv6 bude mít buď můj router přímo, nebo další za ním v řadě (a ten zároveň IPv4). Suma sumárum mi vychází, že IPv6 vůbec nepotřebuju.

[Heron]

Já ani nechci, aby byl každý z těch strojů vidět napřímo.

Mohu se zeptat na důvody? Samozřejmě uvažuji vše za FW.

A abych se připojil k serverům co mají pouze IPv6 snad já IPv6 nepotřebuji, stačí mi, když IPv6 bude mít buď můj router přímo, nebo další za ním v řadě (a ten zároveň IPv4).

Tohle nelze. To by musel někdo vymyslet překlad 6to4 a 4to6 a takovou prasárnu snad nikdo dělat nebude (pokud to vůbec jde). Aby ses dostal na v6 server, potřebuješ v6 konektivitu až ke klientovi.

[pasmen]

Kvůli bezpečnosti přece. Jsem si vědom, že NAT není bezpečnostní opatření, ale nelze popřít, že to případný útok dost ztíží. Vidím to podobně jako existenci vrátnice nebo recepce v domě či firmě.

S tou dostupností IPv6 serveru máš pravdu, měl jsem za to, že když doleze paket na router, IP hlavička se odebere a obalí se novou, tudíž by IPv4/IPv6 router někde na cestě mohl sundat tu IPv4 a nasadit IPv6 a poslat dál po IPv6 trase. Ale je fakt, že to je asi kravina, už jen proto, že klient by musel mít možnost mít v routovací tabulce záznamy pro IPv6 (jasně, lze tam mít pouze default gateway IPv4, ale v zájmu obecnosti...)

[trekker.dk]

Jak to případný útok ztíží? Stroje v tvé vnitřní síti jsou skryté za firewallem a taky NATem. Aby bylo možné prostřelit ten firewall je potřeba získat kontrolu nad tím strojem, který ho zajišťuje. Když máš kontrolu nad tím strojem, NAT není vůbec žádná překážka.

Výsledek: bezpečnostní význam NATu je nula celá nula nula prd.

[Heron]

Kvůli bezpečnosti přece. Jsem si vědom, že NAT není bezpečnostní opatření, ale nelze popřít, že to případný útok dost ztíží. Vidím to podobně jako existenci vrátnice nebo recepce v domě či firmě.

NAT žádným způsobem útok neovlivní. Od toho tu je právě FW*. Jako "vrátnice" funguje např. reverzní proxy, která zachytává všechny (http) požadavky a předává je případně serverům ve vnitřní síti.

*) Odtud možná pochází ta domněnka o bezpečnosti NATu. Zatímco klasické routování žádný firewall na routeru v zásadě nepotřebuje, tak překlad adres ano. A zatímco u routovaných adres je bez FW dostupné vše, tak v případě natu, tak jak jej dělají různé krabičky, není zvenčí přístupné nic. Jenže stejně dobře to lze zařídit i pro globální adresy.

Jak vypadá takový jednoduchý NAT s jednim povolenym portem (snad jsem to nepopletl):

iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT # povolit navázaná spojení
iptables -A FORWARD -i $IFACE_LAN -o $IFACE_INET -j ACCEPT # povolit zevnitr ven
iptables -A FORWARD -i $IFACE_INET -p tcp --dport 22 -d 192.168.0.1 -j ACCEPT # povoleni portu
iptables -A FORWARD -i $IFACE_INET -o $IFACE_LAN -j REJECT # zakazat z venku dovnitr 

iptables -t nat -A POSTROUTING -s 192.168.0.1 -j SNAT --to-source 77.48.22.10 # source nat pro vnitrni ip
iptables -t nat -A PREROUTING --dport 22 -j DNAT --to 192.168.0.1 # presmerovani portu 22 na vnitrni ip 192.168.0.1

Tedy pro jeden port potřebujeme dvě pravidla + další pravidla pro překlad adres packetů směrem ven.

Bez natu se to značně zejdnodušší ale bezpečnost zůstane zachována (a toto by možná chtělo ukzázat všem správcům sítě, kteří trvají na tom, že nat je strašně jednoduchý):

iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT # povolit navázaná spojení
iptables -A FORWARD -i $IFACE_LAN -o $IFACE_INET -j ACCEPT # povolit zevnitr ven
iptables -A FORWARD -i $IFACE_INET -p tcp --dport 22 -d 77.48.22.18 -j ACCEPT # povoleni portu
iptables -A FORWARD -i $IFACE_INET -o $IFACE_LAN -j REJECT # zakazat z venku dovnitr 

Tedy jeden povolený port - jedno pravidlo.

[pasmen]

Já se nechci přít, protože úplně jistý si nejsem, ale třeba mi to aspoň někdo vysvětlí. Ale... Když mám bránu s veřejnou adresou, která má za sebou schovanou síť třeba 192.168.1.0/24, a ta brána se stará o překlad adres, jak je možné zaútočit na stroj uvnitř té sítě (řekněme 192.168.1.100)? Pro jednoduchost ať na té bráně není žádný FW. Pokud se ta brána bude chovat jako obyčejný router, tak pokud na její vnější rozhraní přijde paket s cílovou adresou 192.168.1.100, ona ho propustí až na ten stroj přes své vnitřní rozhraní (např. 192.168.1.1). V tom asi problém není. Jenže problém je v tom, že útočník by musel mít přímou linku k té bráně (bez dalších routerů na cestě). Pokud bude někde v internetu, žádná jeho brána ani router na cestě paket pro 192.168.1.100 nenaroutují. Ne proto, že by na nich byl FW, ale zkrátka proto, že rozsah mé vnitřní sítě není routovatelný. Je až posud moje úvaha správná?

[Michal Kubeček]

V podstatě ano. Existují sice další situace, za kterých by to útočník mohl provést, i když po cestě nějaký router bude, ale ty zase tak časté nejsou. Problém je především v tom, že vy nemůžete své zabezpečení stavět na tom, že útočník tam nebude, zvlášť pokud jste na segmentu s dalšími zákazníky nebo jste připojen přes wi-fi. Proto se v praxi samozřejmě čístá maškaráda bez omezujícího filtru nikde nepoužívá. Pak je ale potřeba si uvědomit, že maškaráda sama o sobě tu síť neochrání, zatímco filtr bez maškarády ano, a udělat ten myšlenkový skok a uvědomit si, že tím, co chrání vaši síť, je filtr (který vám zůstane), ne maškaráda. Naopak, jejím odstraněním se vám zjednoduší konfigurace toho filtru i dalších služeb (směrování, QoS, ...).

[pasmen]

Jasně, asi máš na mysli source routing, ten jsem ani neuvažoval, protože zkušenost mám takovou, že ho skoro nic nepodporuje (nebo blokuje). Ale jsem rád že má myšlenka je jinak správná. A ano, chápu že to není obrana jako taková, neprůstřelná jak beton. Ale zase ať mi nikdo neříká, že to minimálně nesníží počet útoků a celkové riziko.

Jinak tím celým se snažím říct, že zatím nevidím moc důvod přejít na IPv6, a ani si to neumím technicky moc představit. Nějaké výhody bych určitě našel (mezi pobočkami netřeba IPsec tunely, neboť je to integrovaná záležitost IPv6 apod.). Ale jinak nevím nevím. Navíc, když bych přešel na IPv6, mohl bych dosáhnout zase pouze na servery, které jsou IPv6 připojeny, ne? Ostatně to už mi tu někdo říkal a dává mi to smysl. To přece nemůže na nikoho platit. Co jsem tak zjistil, IPv6 konektivitu má cca 0.5% strojů. Jak by tohle vůbec mohlo v nějaké firmě projít, přechod na IPv6, všechno super, ale bohužel už se třeba nedostanete na kb.cz, protože nemají IPv6 konektivitu... (zvoleno jen jako příklad).

[trekker.dk]

Jak by tohle vůbec mohlo v nějaké firmě projít, přechod na IPv6, všechno super, ale bohužel už se třeba nedostanete na kb.cz, protože nemají IPv6 konektivitu... (zvoleno jen jako příklad).

Nemůžu uvěřit tomu, kolik lidí ještě neví o možnostech dual-stacku?

[pasmen]

Neváhej a pouč nás.

[Käyttäjä 11133]

Můžeš mít IPv4 (skutečnou, nebo NAT) a IPv6 na síti v kooperaci...

[pavlix]

Je krásné, jak se tu lidi, co vědí, bez problémů zaskakují... :). Docela dobrý pokrok, že na abclinuxu se dneska už tolik lidí vyzná v IPv6.

[pasmen]

Chápu to tedy správně tak, že každý stroj v mé vnitřní síti (včetně brány) bude mít na svých rozhraních pověšeny jak IPv4 tak IPv6 adresy, a rozeznávat se to bude podle protokolu vyšší vrstvy v hlavičce ethernetového framu? Tohle bych ještě pobral. A jak to bude s default gateway? Bude jedna pro IPv4 a jedna pro IPv6, nebo jsou routovací tabulky obou protokolů úplně oddělené?

[trekker.dk]

Chápu to tedy správně tak, že každý stroj v mé vnitřní síti (včetně brány) bude mít na svých rozhraních pověšeny jak IPv4 tak IPv6 adresy...

Chápeš to správně. Všechny parametry budou nastaveny odděleně. Tj. všechno pro IPv4 (směrovací tabulky, GW) zvlášť a pro IPv6 taky.

O tom, který protokol se použije, pak rozhoduje klientská aplikace (např. Opera když u webu dostane při překladu adresay zpátky IPv6 adresu, tak ji zkouší první)

[pasmen]

OK, dík za vysvětlení. Teď už vidím přechod jako trochu reálnější záležitost.

[Käyttäjä 11133]

Routovací tabulky jsou pro IPv4 i IPv6 úplně oddělené.

[Michal Kubeček]

Ale zase ať mi nikdo neříká, že to minimálně nesníží počet útoků a celkové riziko.

Jak se to vezme. Pokud porovnáte čistou maškarádu a úplně transparentní router, tak na tom maškaráda bude lépe. Pokud porovnáte filtr s maškarádou na jedné straně a samotný filtr na druhé, tak mne nenapadá nic, čím by maškaráda mohla bezpečnosti pomoci.

[pasmen]

Když bych to měl shrnout, NAT mi dává smysl pouze v případě překladu neroutovatelných adres vnitřní sítě na veřejnou adresu brány. V takovém případě jsou automaticky z útoku vyloučení útočníci, kteří nejsou na stejném segmentu jako brána (za předpokladu, že routery na cestě nepodporují source routing, což v praxi platí). Tedy princip maškarády sám o sobě nepředstavuje zabezpečení, ale o tom se nikdo nepře. Samotná existence neroutovatelných adres, a tedy neexistence globální viditelnosti strojů, už podlě mě ano.

[Michal Kubeček]

Problém je opět v tom, že jednak to samo o sobě k ochraně nestačí, jednak když už tam máte filtr (což obvykle máte), nijak to bezpečnost nezvýší.

[pasmen]

Zdá se, že se oba blížíme k nějakému kompromisu či shodě, ale každý z opačné strany a ne a ne se potkat... Ale dobře, já chápu tvůj pohled a souhlasím, že samo o sobě to bezpečnost nezaručuje.

[pavlix]

Za předpokladu použití a aspoň trochu rozumné konfigurace firewallu je prakticky nemožné maškarádou něco získat. Za předpokladu použití ipv6, firewallu a privacy extensions je to ještě patrnější.

Když si to spočítáš, IPv4 maškaráda v podstatě způsobuje, že se koncové počítače adresují 48-bitovými adresami (IPv4+port) stejně jako jejich aplikace. IPv6 je adresuje 128-bitovými adresami (plus 16 bitů na aplikace). Takže už z principu je IPv6 adresní prostor výrazně větši s maškarádou nebo bez ní.

[pasmen]

Já ale nemyslím maškarádou jako takovou, tedy změnou zdrojové adresy paketu, ale samotným faktem, že existují neroutovatelné adresní prostory (kterýžto potom maškaráda slouží).

[pavlix]

Já ale nemyslím maškarádou jako takovou, tedy změnou zdrojové adresy paketu, ale samotným faktem, že existují neroutovatelné adresní prostory).

1) Žádný adresní prostor není neroutovatelný, byť existují doporučení, co se má jak routovat.

2) Jestli se pakety routují nebo ne, je záležitostí konfigurace routeru a firewallu.

3) Maškaráda je primárně nástroj jak síť zpřístupnit, ne jak ji odstřihnout.

4) Pohled typu "tohle by se dělat nemělo, tak se proti tomu nebudeme chránit" je cesta do pekla.

(kterýžto potom maškaráda slouží).

Parse error.

[pasmen]

Hmm, nejsou snad rozsahy typu 192.168.0.0/16 uvedeny v nějakém RFC jako neroutovatelné? Tuším že jsem to někde četl, hádat se nebudu. Bod 2) souvisí s tímto. O účelu maškarády se nepřu. O maškarádě jako takové se vůbec nepřu. Jen situace, které si ji vynucují (existence výše uvedených soukromých sítí) sami o sobě představují zvýšené zabezpečení, dané omezením počtu možných útočníků. Ano, vím o tom, že je to cesta do pekla. Také neříkám se jí držet. Vůbec tady nepopírám správnost řešení čistý router + firewall.

[pavlix]

nejsou snad rozsahy typu 192.168.0.0/16...

To, jak jsou uvedeny v RFC je doporučený způsob konfigurace. Na bezpečnostní stránku to nemá vliv, ta se musí řídit tím, co lze udělat a ne tím, co se dělat má.

sami o sobě představují zvýšené zabezpečení

Ano, představují zvýšené zabezpečení... ale jen do doby, než to zabezpečení snížíš tím, že do té sítě uděláš díru třeba zrovna maškarádou.

To je jako když zamkneš dveře a otevřeš okno. Obecně se říká, že zamčené dveře jsou bezpečnější než nezamčené. Při otevřeném okně se může tento rozdíl úplně vytratit.

Za použití analogie se trošku omlouvám, ale v tomhle případě je na místě.

[pasmen]

Analogie mi nevadí Jinak s těmi adresními rozsahy mi to nedalo, a našel jsem si RFC 1597:

As before, any enterprise that needs globally unique address space is required to obtain such addresses from an Internet registry. An enterprise that requests IP addresses for its external connectivity will never be assigned addresses from the blocks defined above.

Jestli to chápu správně, tak nejde o pouhé doporučení. Pravda, já jsem použil výraz neroutovatelná síť, což je trochu kravina, ale podstata věci tam snad je. Jinak mi ještě vysvětli, jak tam maškarádou udělám díru? Myslíš přesměrováním některých portů dovnitř?

[Michal Kubeček]

Pardon, že se vměšuji, ale já v tom vašem citátu nic o směrování nevidím. Podle mne se tam píše jen to, že adresy z těch tří bloků nebudou nikdy nikomu přiděleny.

[pasmen]

To je pravda. Ale pokud nebudou nikomu přiděleny, jak na ně lze směrovat? Pokud ze své privátní sítě vyšlu paket na třeba 10.0.10.1, pak router nebude vědět co s ním, protože taková síť nikomu přidělena nebyla. Pletu se?

[Michal Kubeček]

Mělo by to tak být. Ale pokud jde o bezpečnost, měl byste si pokládat úplně jinou otázku: "Můžu se na to spolehnout?"

[pasmen]

Ano, souhlasím. Osobně se v praxi nikdy nespoléhám na to, co by být mělo, ale vždy předpokládám ten nejhorší scénář. Tady mi šlo jen o teoretickou rovinu. Myslím, že to tedy lze celé uzavřít Jinak dík za postřehy a vysvětlení všem, jsem zase trochu chytřejší.

[pavlix]

Jestli to chápu správně, tak nejde o pouhé doporučení.

A jakým způsobem útočníka RFC zastaví (za předpokladu, že mu osobně nedáš vytištěným balíkem RFC po hlavě)?

Jinak mi ještě vysvětli, jak tam maškarádou udělám díru?

Na tom není co vysvětlovat. Účelem maškarády přímo je umožnit komunikaci, tedy už ty sítě nejsou úplně oddělené. Navíc maškaráda umožňuje komunikaci obousměrnou, i když obvykle vyžaduje první krok na jedné konkrétní straně maškarádujícího routeru.

Dá se na to dívat i tak, že maškaráda (v jejím obvyklém použití) je služba, která umožňuje počítačům na vnitřní síti otevírat díry, nebo chceš-li tunely do veřejného Internetu.

I tvrzení, že útočník nemůže (za žádných okolností) zvenčí způsobit otevření takové díry nebo tunelu je velmi naivní. Existují různé způsoby, jak přimět počítač na lokální síti (nebo dokonce jeho uživatele) ke spolupráci. Bohužel tyto techniky často stejným způsobem obejdou i některé varianty stavového firewallu.

[petr_p]

I na tom se pracuje (jak čistý IPv6 stroj spojit s čistě IPv4 Internetem). Já jsem si hrál se ptrtd, existuje český pokus wrap6 (nebo tak nějak). Nemohu říct, že to nefunguje.

[pasmen]

A jak by tohle mohlo fungovat? Pokud se chce nějaký počítač spojit s čistě IPv6 strojem, musí přece sám vědět alespoň co to je IPv6 adresa, a alespoň mít možnost najít záznam v routovací tabulce. Není mi jasné jak by to šlo, kdyby on znal pouze IPv4.

[petr_p]

Já jsem mluvil o opačném směru, kdy je spojení navazováno z IPv6 do IPv4.

Ale i pro druhý směr (který nelze úplně vyřešit) se používá finta, že se pomocí DNS pošle odpověď z druhé rodiny protokolu a klient pak vytvoří spojení na pomocný směrovač, který má z jedné strany IPv6 a z druhé strany IPv4, a spojení přeloží.

[pasmen]

Jo tak. I když, pro mě to představuje pořád stejný problém. Pokud je něco čistě IPv4/6, jak může vůbec něco vědět o "druhém světě". A na to, že funguje DNS, se nelze spoléhat

[petr_p]

Samozřejmě že musí existovat nějaká gateway, která má přístup do obou světů. Transcedentální síťová rozhraní se ještě neprodávají :)

DNS tam je proto, že to je společná věc, které rozumí jak v4, tak v6 stroje. Motivací přechodných mechanismů je mít řešení, které nepotřebuje zásahy do koncových stanic. Proto je to takto.

Samozřejmě celou šarádu lze naimplementovat přímo do koncových strojů, takže to bude fungovat i bez DNS, ale obecně se to považuje za příliš nákladné. Navíc by se asi musel standardizovat mapovací prefix, aby se omezila nutnost konfigurace. Prostě by se to muselo pojmout jako třeba 6to4.

Je docela možné, že až se role prohodí a IPv6 Internet bude ve většině, tak se skutečně tak stane a velká peeringová centra budou provozovat anycastové TRT, NAT-PT nebo NAT64 gatewaye.

[pavlix]

A na to, že funguje DNS, se nelze spoléhat

Na fungování DNS nevědomky spoléhá naprostá většina uživatelů Internetu. Mnozí z nich ani neví, co to je IP adresa, a co víc, ani to vědět nepotřebují.

Navíc i tady DNS slouží jen k překladu jmen.

[pavlix]

A jak by tohle mohlo fungovat?

No ono to fungovat nemůže... z čistě síťového pohledu. Jenže z toho stejného pohledu nemůže fungovat ani IP maškaráda (NAT).

Takže pokud uznáš maškarádu za funkční řešení, dá se už vymyslet prakticky cokoliv, tedy i propojení nativní IPv4 s nativní IPv6. Ale samozřejmě se nevyhneš některým omezením, stejně jako u maškarády.

[pavlix]

Víš, on psal za firewallem.

[trekker.dk]

Teď je to pohoda, člověk zná IP adresu každého serveru nazpamět, cca 30 strojů. Představa, že se z těch hezkých adres stane kurník, to by znamenalo minimálně zavedení DNS.

DNS není tak těžké a jestli ti stačí pro vnitřní sítě IPv4 adresy, zapamatovat si IPv6 + nuly navíc asi nebude zas tak těžké - fe80::192.168.0.123 nevypadá tak zle.

[pasmen]

DNS nastavit umím (alespoň základ). Ale jsou to dodatečné náklady, dovolím si říct, že zbytečné (minimálně na železo a čas strávený nastavením a správou).

[trekker.dk]

minimálně na železo

To nemáš žádný stroj, na který bys tuhle výkonově zanedbatelnou službu mohl přihodit...?

[pasmen]

Ale jo, něco by se našlo.

[petr_p]

Nejde o to, kolik adres máte, ale aby byly globální. Až budete do VPN začleňovat další pobočku, která má taky spoustu adres, ale jako na potvoru z kolizního rozsahu, tak pochopíte.

[Aleš Kapica]

Pokud vím, tak má stále IPv6 nedořešené nějaké věci kolem DHCP, protože vytváří adresu z MAC adresy síťovky a tam se může objevit kolize v případě klonovaných virtuálních strojů se shodnou MAC adresou.

[CEST]

No nevim nevim. Klonovany MAC adresy prosim, ale v lokalni siti musi byt vzdy MAC adresa unikatni. Nezalezi na IPv4 nebo IPv6. Lokalne totiz spolu pocitace komunikuji pouze pres MAC adresy, takze tam kolidovat nesmi. A kdyz neni kolize MAC, tak bude mit kazdy pocitac svoji unikatni IPv6 adresu. Naopak DHCP by melo byt v IPv6 v tomhle pripade naopak super, protoze se nemuze stat, ze nejakej pocitac si vezme IPv4 z DHCP serveru, pak se mu rozjebnout hodiny (zpomali) a server si tam IPv4 neobnovi, IPv4 na DHCP serveru vyprsi a server ji prideli nekomu jinemu a nastava kolize. V IPv6 se tohle stane akorat kdyz budou mit dve VM stejnou MAC, ale pak budou kolidovat tak jako tak, at maji IPv4 nebo IPv6. Ale o IPv6 jsem se zatim tak do hloubky nezajimal, takze nevim, co ma za problemy. Rozhodne ale nekteri provideri, poskytovatele sluzeb a "uzivatele" uz IPv6 pouzivaji, takze by snad killer problemy mely byt vyreseny, ne?

[Josef Kufner]

Ono pak záleží, jak je udělaný síťování mezi těmi virtuálními stroji a je docela možné, že to MAC adresy vůbec nepoužívá a má je to jen pro parádu (a aby to nemátlo OS).

[Aleš Kapica]

Přesně tak. K MAC adrese se dostaneš leda tak na stejném segmentu, ale na spojení to vliv nemá. A u virtuálu si můžeš napsat MAC jakou chceš.

[Käyttäjä 11133]

DHCP? Myslíš router advertisement, ne? :)

[pavlix]

Jestli myslel NDP (RA a RS) nebo DHCPv6, to je v celku jedno. Každopádně chci vidět, jak funguje DHCP a ARP na IPv4 při použití stejných MAC adres na virtuálním ethernetu.

[Aleš Kapica]

Stylem kdo dřív přijde, ten dřív mele.

[Aleš Kapica]

Abych to upřesnil. Stačí když někdo přijde s notesem kde má rozjetý "nějaký ten virtuál" co má čirou náhodou stejnou MAC jako nějaký fyzický stroj. Ten pak jenom zařve že danou IP už použíá jiný stroj a nazdar hodiny. To je pak veselo při hledání viníka..

[pavlix]

Jojo, to pak může být hodně veselo, protože při tomhle setupu není na první pohled zřejmé, kde hledat.

[Aleš Kapica]

Metody jsou různé. A to je možná výhoda uzavřených segmentů. Stačí monitorovat síť. Z paketů co lítají se dá zjistit typ síťové karty. A také jiné adresy které na dané MAC adrese ev. visí.

Pokud jsou na cestě switche které lze spravovat, tak lze odchytit port přes který tyto pakety lezou. A tím se i dobrat ke konkrétní zásuvce na které je provinilec napíchnutý. To jsme však u pevné linky. Osobně si nedovedu představit jak tohle lovit u nějakého bezdrátového AP.

[pavlix]

S tím bezdrátem je to problém, no. Ne nadarmo si stát a společnosti třeba GSM síťě dost pečlivě chrání (tím myslím zákony a pokuty, ne jen tecnické prostředky).

[pavlix]

To je hooodně hooodně naivní představa. Ale dobře, existují situace, kdy ta tvoje naivní představa zafunguje.

Ale dokonce i v případě, že zafunguje, tak ze všech virtuálů typu "kdo dřív přijde, ten dřív mele" funguje jen jeden takový stroj. V tom se IPv4 i IPv6 opět shoduje.

[Aleš Kapica]

Však jsem také nikde netvrdil že by problém nebyl společný. Jen to, že dhcp pro IPv6 má být založeno na složení prefixu a MAC adresy a pak se tím pádem může za určitých okolností objevit problém. Nic víc, nic míň.

Ty virtuály to je jen konkrétní upřesnění, za jakých okolností k situaci kdy se v síti objeví dvě shodné MAC může dojít.

[Michal Kubeček]

Ale tady jde o to, že, pokud budete mít na stejném ethernetovém segmentu dvakrát stejnou MAC adresu, tak už to je samo o sobě vážný problém a je úplně jedno, jestli používáte RA nebo ne, dokonce i jestli používáte IPv6 nebo IPv4. Takže argument, že při použití RA se stejné MAC adrese přidělí (nebo spíš může přidělit) stejná IPv6 adresu, postrádá (coby argument proti IPv6) smysl.

[pavlix]

Ten problém nastává zcela nezávisle na tom, jak vypadá IP adresa.

Tys to uváděl jako problém specifický pro IPv6. A on to není problém specifický pro IPv6. Dokonce to není problém specifický pro IP. Ona se ti ta síť pokazí na úrovni L2 (podle modelu ISO OSI), pokud je to síť, která používá MAC adresy (například Ethernet). Síťová (L3) vrstva už s tím nemůže nic dělat.

[trekker.dk]

Zkráceně: bude to problém, i když nad tím ethernetem bude běhat IPX.

[pavlix]

Díky, moc jsem se zabral do technické stránky :) :D.

[petr_p]

Kde jste přišel na dhcp pro IPv6 má být založeno na složení prefixu a MAC adresy? Tohle samozřejmě není pravda.

Za prvé pro identifikaci DHCP klientů se nepoužívá linková adresa, ale DUID, což je víceméně náhodné číslo.

DHCP má stavovou (přidělování adres a delegace prefixů) a bezstavovou část (další nesouvisející volby jako jsou adresy DNS, SIP, NTP serverů). Přidělovaná adresa samozřejmě může být zcela nezávislá na EUI adrese, proto je to stavový protokol, kde se klient se serverem na adrese dohaduje.

A nakonec zrovna tak jako u bezstavového přidělování adres oznamováním směrovače je povinná detekce násobných adres.

[Michal Kubeček]

Kde jste přišel na "dhcp pro IPv6 má být založeno na složení prefixu a MAC adresy"?

Pravděpodobně někde narazil na popis bezstavové autokonfigurace a domníval se, že to je jediná možnost.

[Käyttäjä 11133]

Na to jsem ho ale už několikrát v této diskusi upozornil... a on pořád mele svou :D

[Aleš Kapica]

Zklidni hormon. Jednak jsem to zmnínil. Podruhé jsem pouze upozornil na to že se domnívám - tedy nikoliv tvrdil. Kdysi jsi býval docela slušný kluk, bohužel musím konstatovat, že jsi pochytil hodně z manýrů páně Bourka.

[pavlix]

Přidělovaná adresa samozřejmě může být zcela nezávislá na EUI adrese

Já bych to neviděl zdaleka jako samozřejmost. V případě klasického DHCP (IPv4) je ta závislost implementována na DHCP serveru.

V případě automatické konfigurace IPv6 pomocí NDP bez privacy extensions je ta závislost dokonce algoritmická.

Zcela nezávislá nemusí být ani při použití DHCPv6, pokud se jako DUID použije EUI (což jde).

Takže ano, je možné používat DHCP(v4) i DHCPv6 tak, aby adresa byla nezávislá na EUI, ale zdaleka bych to neoznačil za samozřejmost.

[petr_p]

Bavíme se DHCPv6, ne? Takže do toho IPv4 nebo RA netahejme.

Abychom byli přesní, tak nám jde o DUID Based on Link-layer Address [DUID-LL]. Píše se tam:

… as long as that interface provides a unique link-layer address…

a ještě výše:

The DUID is designed to be unique across all DHCP clients and servers

The motivation for having more than one type of DUID is that the DUID must be globally unique,

Pro zařízení, která toto nesplňují, existují jiné způsoby tvorby DUID.

[pavlix]

Bavíme se DHCPv6, ne?

Já se snažil reagovat na vlákno jako celek. A těžko říct, jestli měl Aleš Kapica na mysli DHCPv6 a neměl tušení, jak funguje, nebo jestli měl na mysli RA a nevěděl, jak se to správně jmenuje.

Mno... díky za citace, ale už jsem je četl několikrát a při reakci na tvůj příspěvek jsem si to pro jistotu procházel znovu. Takže to na mé reakci asi nic nezmění.

V RFCčkách se občas najdou idealistické kecy. Teď nekritizuju, spíš konstatuju. To, že v RFC tvrdí, že něco bude nějak, ještě neznamená, že to praxe na 100% potvrdí.

Neřeknu přesné postupy... ty většinou implementátoři pochytí dobře. Ale ve chvílích, kdy RFC překračuje meze popisu komunikačních protokolů, to může dopadnout úplně jinak. Viz třeba doporučení ohledně reverzních DNS záznamů, nebo třeba generování náhodných částí IPv6 unique local addresses.

Nevěřím tomu, že když chce někdo předvést vytvoření lokálního IPv6 subnetu a pingu na síti, jejíž jediný účel je právě toto předvedení a životnost pět minut, bude takový člověk pečlivě generovat náhodnou část prefixu a neosází ji co já vím třeba nulami, které se dají ještě pěkně zkrátit :).

Pardon za odbíhání od tématu.

[SAM:]

No docela bolává noha je RA (bezstavové nastavení IPv6 adresy) v Mikrotik RouterOS. Už to několik měsíců beznadějně řeším na jejich fóru. Pointa je v tom, že RA prostě nechodí, když se má odesílat přes rozhraní, které je bridgem. (Mám br0 = eth0 + eth1 + eth2 + ath0). RADVD daemon v ROS se tváří, že RA packet odeslal, ale do sítě se nic nedostane (potvrzeno Wiresharekm).

Takže shrnuto v některých zařízeních jsou IPv6 implementace takové dost syrové.

[pavlix]

Tak ono se stačí u Mikrotika podívat na poslední verzi, ke které vůbec existuje oficiální (hotová) dokumentace.

[SAM:]

A jako co? Stable je ROS 4.9 - nechodí to -> je to bug. Měli by s tím pohnout.

[pavlix]

A co já s tím?

[SAM:]

No, že jsi psal něco o dokumentaci? Nevím jak kompletní dokumentace souvisí s bugem v ROSu.

[pavlix]

Ono není důležité, že jsem psal něco o dokumentaci. Ale co jsem o té dokumentaci psal.

Konkrétně jde o to, že Mikrotik byl už nějakou dobu dost pozadu s dokumentací, což vyvolává jistou dávku nedůvěry v celý jejich produkt (software) a zvlášť podporu.

[Heron]

Souhlasím. Dnešní verze ROS 4.9, poslední dokumentovaná verze 2.9 a wikina nepokrývající vše nevrhá na Mikrotik zrovna nejlepší světlo. Forum je sice plně funkční ale to dokumentaci nenahradí.

[Aleš Kapica]

Třeba to že z něj děláš apriori blbce aniž bys věděl jestli se už s tou dokumentací seznámil nebo ne.

Je to úplně stejné jako s tou IPv6. Já se nikde na roli odborníka v této oblasti nepasoval. IPv6 pro mne začne být aktuální až s ní bude mít smysl něco dělat. To co jsem zmínil jako problém pouze vyplynulo jako výsledek debaty s kolegou co to má u nás na starosti. A důvod proč u nás IPv6 zatím nepojede jsem zmínil níže - hraniční router.

[pavlix]

Třeba to že z něj děláš apriori blbce aniž bys věděl jestli se už s tou dokumentací seznámil nebo ne.

To jsi špatně pochopil. Byla to narážka na neexistenci oficiální dokumentace pro novější verze RouterOS.

Btw, já z nikoho blbce udělat neumím, pokud se to někomu stane, většinou si to způsobí sám. To ale není případ MarSarKa.

[Aleš Kapica]

Je to možné. V tom případě se omlouvám.

[pavlix]

Omluvy není třeba, tohle se může stát každému.

[pavlix]

Pokud vím, tak má stále IPv6 nedořešené nějaké věci kolem DHCP

Tyhle problémy má DHCP na IPv4.

Nevím proč pořád někdo musí z neznalosti kritizovat speciálně IPv6 kvůli vlastnostem, které se týkají IP protokolu obecně.

[CEST]

proč tito (a to prosím nejsou žádné IT lamy, jedná se o programátory, správce sítě a v jednom případě dokonce i šéfa IT oddělení) lidé odmítají IPv6

Programator - i kolega tvrdi, ze programtor je linej, jenze to je trosku jina lenost, nez kterou ma admin. Adminova lenost pusobi tak, ze admin premysli, jak napsat efektivni skript, ktery celou praci udela. Programatorova lenost programatora akorat donuti ten kod od nekud zkopirovat. Takze, proc by programator mel prepisovat kod pro IPv6?

Spravce site - IMHO je linej se ucit novou vec, nebo se boji, ze tomu nebude rozumet.

Sef IT oddeleni spis bude manazerskej typ, kterej tomu sam houby rozumi, osobne bych tohohle tipoval na toho s tim routerem a nesmyslnyma pravidlama v routeru.

Rekl bych, ze mas zrovna stesti na radoby-odborniky.

Osobne bych IPv6 rad pouzival, problem je ta dostupnost. Par ISP mozna IPv6 nabizeji, ale zbytek na to kasle. Proc? Protoze aktualizovat HW bude stat sileny prachy, nutnost aktualizovat konfigurace a software bude stat taky sileny prachy. A kdo to pak od nich bude vyuzivat? Par profiku, protoze normalni BFU je jedno, co pouziva, hlavne kdyz mu bezi seznam, nova a dalsi weby. Takze ISP do toho nepujdou, dokud je zakaznici neprinuti. A zakaznici je neprinuti, protoze tem internet funguje. A poskytovale sluzeb jedou taky na IPv4, protoze zakaznici jsou prevazne na IPv4, takze proc by svoje sluzby meli za velky prachy predelavat na IPv6, kdyz o to neni zajem?

Ono by to chtelo, aby centralni autorita zacala IPv4 stahovat z obehu a zastavovat provoz IPv4. Proste odebrat a zablokovat nepouzivane IPv4. Pak dat termin na rozjeti IPv6 a v tom terminu odebrat dalsi IPv4. Rozdavat dalsi IPv4 je nesmysl. Meli by proste rict, zadny dalsi IPv4 uz nedame, a za pul roku odeberem tuhle cast IPv4, prejdete na IPv6.

[Heron]

Programator

Opravdu líný programátor si podle mě vybere takovou třídu pro síťovou komunikaci, která takové sprostoty jako IPv4/6 nebo URL vyřeší za něj. On prostě jen chce, aby se ten program připojil.

Sef IT oddeleni spis bude manazerskej typ, kterej tomu sam houby rozumi, osobne bych tohohle tipoval na toho s tim routerem a nesmyslnyma pravidlama v routeru.

Ne, ten šéf není typický manager a není to tentýž jako s tím routerem. Je to vynikající technik ovšem s takovou povahou typu: "64b nenasazovat, jsou s tím problémy" - tedy raději ani nezkoušet; "jednou se mi pokazil disk Seagate / monitor Samsung a proto jsou tyto značky špatné". Stejně tak "jsou s IPv6 problémy a navíc IPv4 stačí".

Rekl bych, ze mas zrovna stesti na radoby-odborniky.

Tak to není, jen jsem vybral extrémy.

[pavlix]

Ve kterém programovacím jazyce a kterém síťovém interface (knihovně) je prosím potřeba přepisovat kód kvůli podpoře IPv6?

[pavlix]

Samozřejmě se mi jedná o aplikační programování, tzn to, kde programátoři opravdu takto líní jsou.

[Ondrej 'SanTiago' Zajicek]

Treba v C (sockets), pokud programujes aplikaci vyuzivajici UDP (nebo treba multicasty), tam se rozhrani v mnoha rysech lisi. Na druhou stranu, alespon je na IPv6 vcelku standardizovane, zatimco na IPv4 se lisi i mezi Linuxem a BSD.

[pavlix]

UDP jsem v nějakém základu používal a nevšiml jsem si rozdílů, které by nešly vyřešit jenom pár řádky (pamatuju si akorát rozdíly v minimální MTU)... ale dejme tomu. Naopak na TCP jsem v podstatě žádný problém neviděl (jo tuším, že existovaly nějaké starší IPv4-only funkce pro dns, ale to je tak všechno).

[Karel Zak]

Ono

to je tak všechno

u prumerne linuxove distribuce byla prace pro nekolik desitek lidi a mnoho patchu. Ten prechod z IPv4 na v6 neni tak primocary pokud musite projit hromadu kodu.

Jinak pekne how-to: http://people.redhat.com/drepper/userapi-ipv6.html

[pavlix]

Ono je v podstatě jedno, kolik to zabralo průměrně, když to některé distribuce mohly už potom (víceméně) pouze převzít.

Chápu, že u některého software to dalo práci, ale jak je vidět, ve světě opensource se to velmi dobře dařilo.

Já jsem se k síťovému programování dostal relativně pozdě a už i na IPv4 jsem používal getaddrinfo, které má svoje opodstatnění i tam. Přesun na IPv6 mi takto napsaných tcp aplikací už ani nepřišel znatelný.

[Ondrej 'SanTiago' Zajicek]

Slusny UDP program (doporucuje to nejake RFC) nastavuje zdrojovou adresu odchozich UDP odpovedi podle cilove adresy prichozich UDP dotazu. To se resi v IPv4 Linuxu pomoci socket option/control msg IP_PKTINFO/IP_PKTINFO a struktury struct in_pktinfo, v IPv4 BSD pomoci IP_RECVDSTADDR/IP_SENDSRCADDR, a v IPv6 pomoci IPV6_RECVPKTINFO/IPV6_PKTINFO a struktury struct in6_pktinfo. Nic zasadniho, ale upravy to jsou.

[pavlix]

Vidíš, to mě ani nenapadlo. Díky.

[Michal Kubeček]

Podle mne se "popírači IPv6" mezi odbornou veřejností dělí na dvě skupiny. První jsou ti, kteří úspěšně parazitují na současném bordelu a vydělávají na něm. Ať už tím, že pod označením "připojení k Internetu" prodávají zákazníkům služby, které mají se skutečnou konektivitou pramálo společného a za skutečné připojení si účtují mastné příplatky, nebo přímo prodejem zařízení a služeb, které by po přechodu na IPv6 ztratily veškerý smysl (to jsou vlastně ti, kteří ten bordel pomáhají vytvářet).

Druhou skupinou jsou uživatelé, kteří ze současného stavu sice nemají osobní prospěch, ale přechodem na IPv6 by se jim "zhroutil svět". Jsou to lidé, kteří nepamatují staré dobré časy end-to-end konektivity, takže jim ani nemohou chybět. Oni se seznámili s Internetem až v době, kdy už se svět dělil na klienty za maškarádou a servery s veřejnou adresou. Nezřídka jsou přesvědčeni, že maškaráda je bezpečnostní prvek, a z představy veřejně adresovatelné uživatelské stanice jim naskakuje husí kůže (není divu, většina z nich má problém vstřebat rozdíl mezi adresovatelností a dostupností). Na představě dvou strojů ze stejné firemní sítě, které se spolu baví přes server na druhém konci světa, nevidí nic špatného, protože "tak se to přeci dělalo odjakživa". Pokud je problém se spoluprací některého protokolu s maškarádou, je to pro ně automaticky chyba toho protokolu, protože maškaráda je pro ně nezpochybnitelná součást fungování Internetu a dost možná i celého vesmíru. Vysvětlit takovým lidem, že ty obezličky, které považují za nutné, jsou ve skutečnosti jen zbytečnou komplikací, je nadlidský úkol, protože se na vás budou dívat, jako byste jim tvrdil, že neplatí gravitační zákon.

[Heron]

Jako vždy perfektně shrnuto.

+1

[pavlix]

Na tenhle komentář si snad schovám odkaz.

[Ivan]

Pak jsou jeste takovi, kteru jeste nenasli pouzitelny HW. Taky treba zjistili ze kvuli IPv6 musi upgradovat bind na verzi ktera umi poradne filtry a ze je to stejne nejaky pomaly. Ze jeste nekde pouzivaji Apache 1.3.x kterej ale IPv6 podporovat nebude a ... Implementace IPv6 je spouta, kterou bude muset nekdo zaplatit. A pak kdyz to bude implementovano taky se musite pripravit na soustu stiznosti od uzivatelu, napr. Eclipse neumi stahnout updaty pokud mate na pocitaci funkcni IPv6(nejaka chyba v JVM), IE na WinXP s funkcni podporou IPv6 nekorektne zpracovava DNS odpovedi, ....

[Jirka]

Že by Eclipse neuměl stáhnout updaty na počítači s IPv6 adresou jsem si nějak nevšiml. A s tím IE jde konkrétně o jaký problém? Běžně IE nepoužívám, ale teď jsem zkusil verzi 8 na WXP s aktivním IPv6 a funguje překlad jak při přístupu přes IPv6, tak IPv4.

[Jirka P]

Že by Eclipse neuměl stáhnout updaty na počítači s IPv6 adresou jsem si nějak nevšiml.

IMHO předřečník narážel na toto. Nejde ani tak o IPv6 adresu, jako o systém, který má IPv6, ale jen IPv4 konektivitu.

[Let_Me_Be]

IPv6 na strane infrastruktury neni problem. Maximalne jde o vymenu trochu HW, ale drtiva vetsina HW, uz IPv6 alespon v nejake zakladni variante umi davno.

IPv6 na strane koncove infrastruktury je docela problem. Chytre switche a routery pro domacnosti a male podniky maji s IPv6 porad problemy.

IPv6 u poskytovatelu pripojeni pro domacnosti je problem, protoze by to pro ne znamenalo praci na vic a na to kazdy dlabe (hlavne kdyz neni tlak ze strany uzivatelu).

IPv6 u koncoveho SW je naprosto fatalni problem. Minimum aplikaci je pripraveno na IPv6. Nejhorsi je stav u aplikaci, ktere funguji sloziteji nez systemem klient<->server.

IPv6 na strane serveru vicemene nikoho nezajima, protoze at uz server pojede na IPv6 nebo na IPv4, stejne na nej polezu pres DNS a ne pres IP adresu.

[otasomil]

Mate pravdu.

Asi nema cenu to hrotit.

FBU tento problem nezajima, casto ani nevi co je IP adresa natoz v4 ci v6.

ISP to obejdou po svem. Napr 1 vesnice (access point) = jedna IP - zakaznici ziskaji adresu v rozsahu 192.168.neco.neco.

Internet jim pojede a vic je nezajima a ani nechce zajimat.

O verejne ci neverejne IP nema naprosta vetsina uzivatelu ani paru.

 

Jinak myslenka IP v6 je samozrejme velmi dobra a moznost mit libovolny stroj k dispozici odkudkoliv je vyhoda, ale zas jen pro hrstku lidi co to potrebuji a nebo se o IT zajimaji z pohledu sitoveho provozu.

[Heron]

Jinak myslenka IP v6 je samozrejme velmi dobra a moznost mit libovolny stroj k dispozici odkudkoliv je vyhoda, ale zas jen pro hrstku lidi co to potrebuji a nebo se o IT zajimaji z pohledu sitoveho provozu.

To ale není celá pravda. Konektivitu potřebuješ nejen tehdy, pokud se chceš explicitně připojit domů ale i v dalších a daleko běžnějších případech. Vem si třeba jen chat nebo voip komunikaci dvou lidí. Dnes je zcela běžné, že to jde z jednoho PC na server (nebo v případě skype k nějakému nicnetušícímu chudákovi s veřejnou adresou) a na druhé PC. Přitom by to mělo jít přímo, bez mezičlánku. Jak píše Michal Kubeček, dnes už si přímé spojení někteří lidé ani neumí představit. Také posílání dat (fotek, dokumentů) dnes spousta lidí zcela automaticky řeší tak, že to uloží někam na webovou úschovnu a dají odkaz kamarádovi. Přitom se opět mohou spojit přímo. Atd.

Bohužel, dnes je nutné vysvětlovat něco, co dřív (před síťovou maškarádou) bylo zcela přirozené .

[pavlix]

Jinak myslenka IP v6 je samozrejme velmi dobra a moznost mit libovolny stroj k dispozici odkudkoliv je vyhoda, ale zas jen pro hrstku lidi co to potrebuji a nebo se o IT zajimaji z pohledu sitoveho provozu.

Byly doby, kdy tohle platilo pro provozování IP a pro přístup k Internetu obecně.

[ZeXx86]

Nechapu co resite, vzdyt zavest ipv6 konektivitu je zalezitost par minut v lokalni siti. Staci /64 a radvd na routeru. Na stanicich nic nastavovat nemusite. Pak uz zbyva jen prenastavit potrebne programy, aby ipv6 pouzivaly.

[Jirka]

Jo. Na domácí síti je to jednoduché. S velkými sítěmi, kde se řeší monitoring, účtování, QoS atd. je to složitější.

[otasomil]

Casem prijdete na to ze spousta technologii, veci .... jsou na velmi vysoke urovni, kvalitni ...

ale nikdo je nechce.

Proc ?    ........ poznate, kazdy casem pozna a pochopi.

Mozna s IP V6 je to obdobne.

[pavlix]

Mozna s IP V6 je to obdobne.

Možná, možná ne :).

To mi nicméně nijak nezabrání ho začít používat. Zvlášť, když sjem zjistil, že se sním učí jak můj domácí poskytovatel, tak můj poskytovatel virtuálů... a takovéty služby pro geeky typu vpsfree považují IPv6 dnes už za samozřejmost.

Takže co je lepší argument? Hospodské kecy (případně jejich obdoba pod blogy) nebo reálné nasazení v konkrétních případech?

[Aleš Kapica]

Kašpárci co tady hledají máslo na hlavě adminů. Rád bych vás upozornil, že občas taky může být problém v tom, že hraniční router prostě technologii IPv6 nepodporuje. A pokud vám takový router nepatří, těžko můžete jeho vlastníka nutit aby na nic nedbaje kmital do krámu koupit nový jen proto že vy chcete používat IPv6.

Každá sranda něco stojí, což byste si měli uvědomit zvláště v dnešní době, kde každý hledá na čem by nějaké ty love uškrtil.

[trekker.dk]

No a ty by sis, kašpárku, zase mohl uvědomit, že IPv6 není žádná novinka a IPv6-enabled zařízení taky ne. Jestli něčí hraniční router prostě IPv6 nepodporuje, dotyčný při jeho nákupu nemyslel dost dopředu a stále tedy má máslo na hlavě.

[Aleš Kapica]

Odendej si bambulky z očí. Možná ti pak z textu docvakne že ne vždy si můžeš nadiktovat přes koho a co se můžeš připojit.

[pavlix]

Člověče tohle snad ani nezaslouží inteligentní komentář. Tak nic.

[Michal Kubeček]

To je sice pravda, ale nechápu, proč by mne taková skutečnost měla vést k závěru, že chyba je v IPv6 a že přechod na IPv6 nemá smysl. Např. můj poskytovatel připojení také nenabízí IPv6 konektivitu a ani se nesnaží předstírat, že se k tomu chystá. Ale z toho přece nevyplývá, že je problém v IPv6, problém je v tom providerovi (a tom, že si nemůžu moc vybírat).

[Aleš Kapica]

Nikde jsem nepsal že je chyba v IPv6, pouze že za určitých okolností může vzhledem k tomu jaká je tvorba IPv6 adres, vznikat problém. Tudíž přechod na IPv6 není otázkou jednoho nastavení.

K reakci mě vyprovokovala argumentace osob, které všeználkovsky vytrubují, že v nasazení IPv6 žádné problémy nejsou. A to jen na základě toho, že zrovna oni je neřeší.

[trekker.dk]

pouze že za určitých okolností může vzhledem k tomu jaká je tvorba IPv6 adres, vznikat problém.

Což není pravda. V uvedené situaci problém vznikne bez ohledu na to, jaký používáš protokol na síťové vrstvě.

[pavlix]

vzhledem k tomu jaká je tvorba IPv6 adres

Vidíš a kdybys četl reakce, tak by sis konečně uvědomil, že v tomhle konkrétně nemáš pravdu.

A že daný problém s tvorbou IPv6 adres nijak nesouvisí.

A rovněž nemáš pravdu v tom, že se takhle adresy při použití DHCPv6 tvoří.

Nadávat na všeználky je ok, pokud se aspoň minimálně vyznáš v tématu.

[pavlix]

Taky by sis měl uvědomit, že už teď lidi tady ztrácí naději, že téma pochopíš... a postupně píšou už jenom proto, aby náhodou někdo neměl tu smůlu, že si přečte tvoje příspěvky a bude si myslet, že to co píšeš dává nějaký smysl.

Jenže ty ne, ty klidně mícháš mezi sebou L2 a L3... vedle toho mícháš mezi sebou DHCP(v6) a stateless autoconfiguation.

[trekker.dk]

Možná ti pak z textu docvakne že ne vždy si můžeš nadiktovat přes koho a co se můžeš připojit.

Jak toto něco mění na tom, co jsem napsal výše?

[Aleš Kapica]

A jak tvůj příspěvek souvisel s tím, že někdy může existovat i objektivní příčina?

[trekker.dk]

Tvůj příspěvek:

Kašpárci co tady hledají máslo na hlavě adminů. Rád bych vás upozornil, že občas taky může být problém v tom, že hraniční router prostě technologii IPv6 nepodporuje.

Poukázal jsem na to, že adminové, kteří kupovali ten hraniční router, mají stále máslo na hlavě. Ostatní tvé příspěvky v tomto vlákně jsou jenom bláboly, protože nevíš, kam bys vycouval.

[xxx]

Je chyba domnívat se, že jde primárně o zařízení. Jistě ve firmě, kde jsou tři servery, třicet kompů možná ano. Jenže tam to ten správce dá do kupy poměrně bezproblémově.

Horší to začne být v okamžiku kdy jste firma a méte těch serverů 150 v několika různých hostinzích, řešíte QoS, accounting a jiné věci. Zavést v takovém případě IPv6 pro jednoho zákazníka není problém. Možná, že ani není problém zavést IPv6 obecně mezi svými prvky. Problém je ale vytvořit postupy pro obecné nastavení a otestovat je (od fw, přes nějaký plán adres, atd). A prostě nesmíte udělat chybu, která vám pošle celou vaší síť do kytek. Navíc tohle stojí peníze, které vám nikdo nedá. A dokavaď bude únosné řešit IPv6 on-demand, tak se do toho nikdo nepohrne.

[trekker.dk]

Je chyba domnívat se, že jde primárně o zařízení.

To taky netvrdím...

Horší to začne být v okamžiku kdy jste firma a méte těch serverů 150...

Zkráceno: nasazení IPv6 znamená práci. Njn, holt nikdo nemůže čekat, že zavedení nějaké novoty půjde samo. Háček je ale v tom, že pokud nebudeme chtít vymýšlet ptákoviny typu NAT na straně serveru, tak se ta práce prostě dřív či později bude muset udělat.

[xxx]

V momentě kdy bude potřeba nasazovat obludnosti typu NAT na serveru, tak v ten okamžik už tu "nadsdandartní"práci budete muset udělat.

[trekker.dk]

No a já právě tvrdím, že by bylo možná lepší udělat to dřív a nečekat.

[pavlix]

Jenže problém je v tom, že to co je z globálního a dlouhodobého hlediska výhodné... těžko bude dělat firma, která plánuje jen na půl roku až rok dopředu.

[pavlix]

Kašpárci co tady hledají máslo na hlavě adminů.

Kašpárci, co se věčně na něco vymlouvají... počkejte, až budou zajímavá pracovní místa obsazena těmi, co se vymlouvat nepotřebují.

[Aleš Kapica]

Na to si rád počkám. Prozatím na nich totiž sedí bohužel docela pevně. Naopak mám silný pocit, že opět současná doba posiluje představu, že pokud někdo nepobíhá zběsile po chodbách od jednoho stroje k druhému tak je vlastně zbytečný a lze ho tím pádem propustit.

[pavlix]

Naštěstí jsem neměl tu možnost si toho všimnout.

[vencour]

Neděláš na nějakym ministerstvu?

[Aleš Kapica]

Poslední dobou mám takový pocit.. Ale ne. Stačí použít google.

[vencour]

No jo ... co mam ponětí, tak školství je na tom jen o něco málo líp, než zdravotnictví.

[Aleš Kapica]

Ano. Zatímco kotelníci už jsou pod vodou, nám to omývá kotníky a kapela stále vyhrává... A jelikož čluny nejsou pro všechny, začínají někteří cestující divočet.

To jsem ale odběhnul. Skutečně jsme narazili na to, že je problém v hlavním CISCO routeru, který zrovna jako na potvoru IPv6 nepodporuje. Všechna ostatní zařízení ano. Jenže tenhle router není majetkem naším, nýbrž Správy budov(?) No zkrátka, tady už jsem na tenkém ledě. Stejně během roku na podobné hrátky není vhodná doba. Takže někdy v létě. Snad. A když se do toho namanou podobné hurá akce jako ta co je naplánovaná na příští týden, tak nějaké IPv6 padá v žebříčku priorit níž a níž.

[trekker.dk]

Naopak mám silný pocit, že opět současná doba posiluje představu, že pokud někdo nepobíhá zběsile po chodbách od jednoho stroje k druhému tak je vlastně zbytečný a lze ho tím pádem propustit.

Neřekl bych, že to bude dobou, spíš tvým výběrem zaměstnavatelů.

[Aleš Kapica]

Někdy si říkám jestli jsi vážně tak blbý, nebo to jen hraješ. Já na rozdíl od tebe se nijak netajím s tím kde, co a pro koho dělám. Dá se to snadno dohledat. I to je jeden z důvodů, proč bych si nedovolil psát něco co by nebylo pravda a proč v takovém případě píšu o pocitu. Navíc jsem nenapsal že, by měl tuhle představu můj zaměstnavatel.

[trekker.dk]

Já na rozdíl od tebe se nijak netajím s tím kde, co a pro koho dělám.

No spíš je to tak, že já to nevytrubuju do světa při každé aspoň trochu možné příležitosti. Narozdíl od tebe, který si při té příležitosti obvykle rovnou nad něčím zabrečíš.

[Aleš Kapica]

Pochopitelně, je-li to k pláči. Kupř. nad tvými příspěvky pláču skoro pořád. Obvykle mi přitom jeden hlas v hlavě zoufale říká: "Ty vole proč jsi ten jeho sbalený příspěvek zase rozklik.." Načež mu druhý oponuje: "Ale co když to tentokrát mohlo být i něco co mohlo stát za přečtení?"

[trekker.dk]

Ano, rozklikávat moje příspěvky s rizikem, že tam opět bude argument, proti kterému nebudeš moct nic vyhrabat, to je opravdu k pláči.

Nicméně pokud se tak zoufale chceš věnovat rozumné diskuzi, doporučuji ti přestat opomíjet například #55

[Aleš Kapica]

A?

Nějak mi unikla pointa tvého vtipu.

[pavlix]

Někdy si říkám jestli jsi vážně tak blbý, nebo to jen hraješ.

Chlape tobě už asi vážně došly zbytky rozumných argumentů.

[vencour]

Hraniční router mezi dvěma AS neumějící IPv6? O takovém nějakém konkrétním víte? Cisco i Juniper se holedbají tim, jak jsou ready.

[Aleš Kapica]

Ano vím. Přesně na tohle jsme totiž narazili, když jsme s kolegy řešili co je třeba pro to abychom mohli spustit na nějakém segmentu v testovacím provozu IPv6.

[vencour]

Že by na starý železo nebylo novější nebo bugfree vybavení?

[Aleš Kapica]

Možná to někomu přijde směšné, ale momentálně díky skvělým protikrizovým opatřením někteří nemají finance málem ani na pastelky, a to je teprve květen. Není divu že takovým jsou pak solí v očích výdaje na podobná zařízení, která jsou z jejich pohledu naprosto zbytečná.

[pavlix]

Ještě že já na pastelky mám :).

[Aleš Kapica]

Počkej až ti je někdo začne závidět

[pavlix]

Přihlašte se, kdo chcete dostat od pavlixe pastelku :).

[Käyttäjä 11133]

Já já já já já

[pavlix]

Ty k nim dostaneš ještě bonusový pivko za krásné příběhy z cest :).

[trekker.dk]

Možná to někomu přijde směšné, ale momentálně díky skvělým protikrizovým opatřením někteří nemají finance málem ani na pastelky, a to je teprve květen.

Čímž se vracíme zpátky k tomu, že někteří byli před pár lety málo prozíraví.

[Aleš Kapica]

Když všemu tak dobře rozumíš a jsi tak skvělý čtenář budoucnosti.. Co takhle nabídnout své služby při nejbližší prezidentské volbě? "Jirka Bourek for president!" Třeba by to klaplo a tvé rozumy by tak konečně prospěly dobré věci. Vzhledem k tomu že horší už to stejně asi být nemůže, klidně bych tě i svým hlasem podpořil.

[trekker.dk]

Když všemu tak dobře rozumíš a jsi tak skvělý čtenář budoucnosti..

Tvá snaha obrátit všechno v ad hominem je dojemná...

Jak starý je ten router? Dva roky? Pět let? Už tou dobou se vědělo, že IPv4 adresy docela brzo dojdou, a jenom díky IANA, která vytáhla z rukávu nějaké triky, se povedlo den D oddálit tak, že ty adresy nedošly ještě dneska.

Ale přesto všichni nakupovali technologie bez podpory IPv6. Ať se budeš snažit jakkoliv, takoví lidé prostě nebyli prozíraví a basta.

[Aleš Kapica]

Zřejmě ti uniklo několik fakt, tak nezbývá než ti je zopakovat.

Ten router nám nepatří. Tudíž o něm nic bližšího (krom typu) nevíme. Tj. kdo kdy za kolik a od koho ho koupil.

Pracuji na VŠ, to je příspěvková organizace. Nákup čehokoliv neprobíhá podle systému co budem potřebovat za rok či dva, ale podle toho co potřebujeme, na co máme a co je k mání za ty prachy teď.

Bohužel to mnoha lidem nedochází.

[trekker.dk]

Zřejmě ti uniklo několik fakt, tak nezbývá než ti je zopakovat.

Žádné ze zopakovaných fakt nic nemění na to, že někdo nebyl dostatečně prozíravý, když to nakupoval. Je z toho vidět, že ti nedostatečně prozíraví jste nebyli vy, ale to jsem taky nikde neřekl.

Pracuji na VŠ, to je příspěvková organizace. Nákup čehokoliv neprobíhá podle systému co budem potřebovat za rok či dva, ale podle toho co potřebujeme, na co máme a co je k mání za ty prachy teď.

Viz #96

[Aleš Kapica]

Koukám že ses nějak zacyklil. Tak dobrou noc.

[trekker.dk]

Zase ad hominem? Dobrá, budu si to vykládat, žes chtěl říct, že jsi se spletl, špatně sis něco vyložil a omlouváš se.

[xxx]

Vás nepřipojuje Cesnet? Protože tam bych ted problém s IPv6 nečekal.

[Ivan]

Oni treba IPv6 umeji. Kdyz k tomu ale pridate pozadavek na podporu MPLS a pokud mate treba implementovanou nejakou klasifikaci packetu a jeji prepis do IP TOS resp. do ethernet QOS tak se dostanete do problemu. Uvedomte si ze cilem ISP neni implementovat IPv6 routovani - to by umel kde kdo. Oni potrebuji zachovat vsechny funkcionality stavajici site (QoS, accounting, monitoring) a tomu potrebuji "pouze" pridat IPv6. IPv6 penize nevydelava, accounting a VPNky ano.

[Käyttäjä 11133]

A pokud vám takový router nepatří, těžko můžete jeho vlastníka nutit aby na nic nedbaje kmital do krámu koupit nový jen proto že vy chcete používat IPv6.

Můžeš honutit úplně snadno. Ty si zákazník, pokud si větší organizace máš velkou páku, A pokud hraniční router neumí IPv6 je to nejspíš starý krám který je potřeba vyměnit tak jako tak...

[Aleš Kapica]

Hele Marku. Je pozdě, už jsi asi unavený. Jdi se opláchnout, protože jak se zdá ti uniklo že ne všude platí pravidla byznysu. Bohužel v tom nejsi sám. Katastrofa je, když si někdo plete příspěvkové organizace se soukromou firmou.

[trekker.dk]

Větší katastrofa je (zákonem stanovený) způsob, jakým příspěvkové organizace nakládají s penězi.

[Aleš Kapica]

S tím plně souhlasím. Nicméně ani jeden z nás nemáme na to jinou páku, než hodit do urny lístek který podpoří stranu o níž si myslíme že to snad udělá lépe.