To by nedávalo smysl. Pokud ten modem dostává přes PD /56, tak v bridge to dostane ten router za tím, protože tak funguje bridge.
Ale jak jsem se dozvěděl později, tak možnost bridge vypnou, přestože to ty modemy umí. Prý protože DS-Lite. Jenže bridge nemá problém s DS-Lite a DS-Lite nemá problém s bridge, je jim to úplně jedno, jsou na jiných vrstvách a tunel se prostě vyvede na router za bridgem. Samozřejmě musíte tam mít něco, co to umí, takže žádný D-Link, ale Linux ani Mikrotik nemá s 4in6 tunely problém.
Do bridge módu modem od UPC (ConnectBox) přepnout jde, ale musíte je trochu zprudit na technické podpoře, defaultně je to v menu schované, asi kvůli lamám.
Já jsem se točil na tom, že na jejich stránkách ve FAQ píšou, že to jde (https://www.upc.cz/pece-o-zakazniky/internet/zarizeni-pro-pripojeni/vypnuti-router-modem/) a v opačném případě, že vypovídám smlouvu. Tři maily během jednoho týdne, nakonec mi volbu v menu modemu aktivovali a dal jsem si za to Mikrotik...
Funguje to tak, že pak přidělí přes DHCP veřejnou nestatickou adresu tomu připojenému zařízení a modem funguje fakt jen jako modem. Vzhledem k děravosti toho krámu celkem fajn ho nemít v lokální síti, ale hezky za firewallem. Ale vzhledem dynamické (i když veřejné IP) si IPv6 moc neužijete, 6to4 nefunguje a žádný jiný pořádný tunelovací provider, který by uměl protokoly pro dynamické endpointy není. Nativní ipv6 nepřidělují.
Možnost přepnutí do bridge byla odstraněna při zavádění IPv6. Pokud v tom vašem bridge na své zařízení dostanete dynamickou IPv4 a žádnou IPv6 adresu, pak nemáte zavedeno IPv6 a v takovém případě bridge režim funguje.
Pokud chcete spolehlivý tunel pro dynamické IPv4 endpointy, HE.net je jeden z nich.
"A když jsem se koukal na další poskytovatele, všichni se svorně tváří, že něco jako ipv6 neexistuje!"
"Využívám služeb dvou ISP a ani jeden v brzké (či daleké) době neplánuje IPv6 zavést"
ISP by nemeli byt pasivni, nybrz by meli vyvinout tlak na prislusne organizace, jich jsou casto cleny, (RIPE, ICANN, IANA, ISOC a pod.) aby urychlene zahajili standardizaci IPv7 zalozeneho na IPv4 se 128bitovymi adresami.
To je nesmysl. IPv4 má 32bitové adresy, takže cokoli, co by mělo adresy jinak dlouhé, by vždy byl jiný protokol. Aby uživatel nepoznal změnu (tj. doma má pořád IPv4) se dá zařídit jedině pomocí nějakého NATu, a přes ten uživatel logicky nemůže mít dostupný celý nový adresní prostor.
Narážel jsem na to, že IPv6 je prakticky opravdu jen IPv4 s delšími adresami, jiné změny v samotném IP protokolu vlastně nikdo neřeší (nezaznamenal jsem žádné stížnosti na trochu jiné zacházení s hlavičkami v IPv6 protokolu – pravděpodobně je to něco hluboko pod rozlišovací schopností objevitelů „IPv4 s delšími adresami“). To, co lidem obvykle na „IPv6“ vadí, není samotný IPv6 protokol, ale přidružené protokoly – pro konfiguraci sítě apod. Takže ty nápady s „IPv4 s delší adresou“ jsou akorát projevem neznalosti dotyčného. Pokud by někdo chtěl IPv4 s delší adresou, vyjde mu zase IPv6, akorát možná ty přidružené protokoly by byly jiné. Jenže pokud jde například o protokoly pro konfiguraci sítě, ty si každý může používat, jaké chce. Takže pokud někdo chce ve své síti provozovat IPv6 s ARP a BOOTP, ať si to klidně provozuje. Jeho hraniční router bude se zbytkem internetu komunikovat přes IPv6, a to stačí, aby byl připojen k IPv6 internetu.
Souhlasím s tím, že IPv6 je v principu IPv4 s delší adresou, ale není jeho náhrada jako taková, protože IPv6 neumí pracovat s IPv4 pakety (snad kromě rozlišení, že je IPv4), třeba jako x64 procesor, který umí zpracovat 32-bitový kód, protože je zpětně kompatibilní. IPv6 v sobě zahrnutý IPv4 nemá. To je myslím jádro veškerých nářků na IPv6. Prostě nový protokol by měl umět ten starší skrze jedno rozhraní bez takových věcí jako je dual stack. Bohužel realita je někde jinde...
IPv6 v sobe IPv4 samozrejme zahrnuty ma a to prostrednictvym namapovani na konkrenti IPv6 prefix.
Dualstack 6to4 a dalsi je pak taky soucasti RFC pro IPv6 ... divny ze?
Predevsim by me pak zajimalo, japa by sis predstavoval, ze bude ten IPv4 stroj komunikovat s tim IPv6 strojem ... kdyz tech IPv6 stroju je 2^40 ... to by me fakt zajimalo.
IPv6 umí pracovat s IPv4 pakety přímo, k tomu slouží 0:0:0:0:0:ffff::/96.
Jaký je problém s dual stackem? Vždyť i ty procesory v 64bitových systémech to dělají stejně, část aplikací jede na 64 bitech a část na 32. Pokud vám ale dual stack vadí, tak IPv6 umí 464XLAT, používají to třeba američtí mobilní operátoři, kteří už dlouho jedou na IPv6-only sítích a ani si toho nevšimnete.
Jinými slovy, jádro nářků na IPv6 je, že IPv6 adresa není zároveň delší než IPv4 adresa a zároveň stejně dlouhá. Když někdo vysloví takový požadavek, je to opravdu k pláči…
Zkuste se zamyslet, jak by to asi vypadalo, kdybyste tím vaším „zpětně kompatibilním“ protokolem poslal ze zařízení s IPv6 adresou paket s cílovou IPv4 adresou. Kvízová otázka zní: jaká odchozí adresa by byla v tom IPv4 paketu? Jak byste tu 128bitovou IPv6 adresu nacpal do 32bitového pole v IPv4 paketu? A než začnete vymýšlet, že byste jí dal do nějaké volitelné hlavičky a jako adresu odesílatele byste uvedl nějaký superNAT, přemýšlejte chvíli o tom, co by s tím paketem dělal cílový počítač (který by měl jen IPv4 adresu) – třeba jak by na něj odpověděl.
Samozřejmě když mluvím o kompatibilitě, tak že IPv6 umí IPv4 a ne naopak. Tím pádem všechny řeči o posílání IPv6 paketu do IPv4 postrádají smysl. Jistěže s IPv4 zařízením by musel IPv6 komunikovat postaru.
Nechci se tu v diskuzi bavit o vymýšlení alternativního protokolu, ale to že IPv6 existuje pěknou řádku let, tu na rootu se o něm mluví taky pěkně dlouho a pořád se řeší jeho pomalý nástup, svědčí o tom, že se k tomu problému nepřistupovalo citlivě.
Samozřejmě když mluvím o kompatibilitě, tak že IPv6 umí IPv4 a ne naopak.
Pod tím si mám představit co? Komunikace na internetu je zpravidla obousměrná. Při použití TCP se pakety vždy posílají oběma směry, UDP protokoly jsou také zpravidla obousměrné – je jen velmi málo případů, kdybyste něco poslal a nezajímala vás odpověď.
Tím pádem všechny řeči o posílání IPv6 paketu do IPv4 postrádají smysl.
To vy jste psal o zpětné kompatibilitě, což je přesně tohle – posílání IPv6 paketu do IPv4. Opačně je to ještě větší nesmysl – jak by podle vás mělo zařízení, které zná jenom IPv4, něco poslat do IPv6, o kterém vůbec neví?
Jistěže s IPv4 zařízením by musel IPv6 komunikovat postaru.
Asi si každý představujeme něco jiného pod pojmem „zpětná kompatibilita“. Takže jestli chápu správně váš návrh, pokud jedno ze dvou zařízení, která chtějí komunikovat, zná jenom starý IPv4 protokol, komunikují přes IPv4. A pokud by obě zařízení znala nový protokol, komunikovala by pomocí něj. Mohl by se ten nový protokol jmenovat třeba IPv6? Tohle už ale vymyslel někdo před váma…
…svědčí o tom, že se k tomu problému nepřistupovalo citlivě.
Nikoli, svědčí to akorát o tom, že o tom autoři IPv6 přemýšleli víc, než autoři výroků o tom, že měl být IPv6 zpětně kompatibilní s IPv4. Autoři těchhle výroků totiž pokaždé, když o tom začnou přemýšlet (škoda, že to nedělají před tím, než ten výrok pronesou) dospějou do dovu možných stavů – buď znovuvynaleznou IPv6, nebo prohlásí „nevím jak, ale určitě by TO šlo nějak vymyslet“. Přičemž za oním „TO“ se skrývá protokol, který by používal adresy, které by byly dlouhé zároveň 32 i 128 bitů. Neb-li autoři IPv6 došli k logickému závěru, že udělat protokol, který bude mít adresy, které budou mít zároveň 128 bitů i 32 bitů, je principiálně nemožné. Proto navrhli nový protokol IPv6 a k němu přechodové mechanismy pro zajištění zpětné kompatibility – dual-stack, různé 6-4-NATy apod.
ale problem je v tom ze oni nenavrhli protokol se 128 bit adresou ale se 64bit adresou + 64 bit prilepkem (obcas adresa obcas neco i jineho).
dalsi nesmysl ktery navrhli je autoconfigurace. O prideleni adres se dle mne ma starat administrator site (DHCP, staticka konfigurace, atd..) a ne samotna zarizeni, ktera se na tom musi domlouvat.
Dalsi vec je sitova maska, kdyby radeji ponechali masku site libovolne dlouhou tak provideri nemaj problem pridelovat site mensi nez 64 a retezit se ve vetsim poctu za sebou
ale problem je v tom ze oni nenavrhli protokol se 128 bit adresou ale se 64bit adresou + 64 bit prilepkem
Nikoli. Protokol IPv6 má 128bitovou adresu. Pouze některé mechanismy přidělování IPv6 adres počítají s rozdělením 64bitů adresa sítě, 64bitů adresa zařízení.
dalsi nesmysl ktery navrhli je autoconfigurace
Podle mne je to naopak výborné řešení. Navíc vás nikdo nenutí to používat.
O prideleni adres se dle mne ma starat administrator site (DHCP, staticka konfigurace, atd..) a ne samotna zarizeni, ktera se na tom musi domlouvat.
Nic vám nebrání ve své síti si to takhle nastavit.
Dalsi vec je sitova maska, kdyby radeji ponechali masku site libovolne dlouhou tak provideri nemaj problem pridelovat site mensi nez 64 a retezit se ve vetsim poctu za sebou
Není žádný důvod přidělovat menší sítě, než /64. Pokud se provideři řetězí za sebou, má ten koncový přidělovat /64 a ti nad ním větší rozsahy. Když ten vrchní bude přidělovat /64, je to špatně. IPv6 je navržené mimo jiné tak, aby v něm bylo opravdu dost IPv6 adres, nešetřilo se jimi a usnadnilo se tak routování. Šetřit IPv6 adresami je v rozporu s návrhem tohoto protokolu.
ja jsem v praze na centriu a ti nejen ze doposud ipv6 nežají, ale neplánují ho ani do budoucna, bohužel konkurenční upc zase nenabízí simerické linky takže když jsem nahrával video na utube tak byl několik hodin nepoužitelný celý internet. kdybych o tom rozhodoval já tak bych těmto operátorúm odebral licenci a dráty přenechal jiným.
Tak oni hlavne zadnou sestku nikomu davat nebudou, protoze to nejsou schopny udelat. A ti, kteri to nemaji si muzou leda gratulovat, protoze na 4ce si 6tku tunelem zprovoznej, ale za CGN si port na 4ku nenaforwardujou ... pricemz ten zvanil jasne deklaroval, ze tem co dostanou tu pseudosetku nedaj ctyrky ...
UPC symetrické linky i IPv6 nabízí, ale za korporátní peníze. Za tisícovku měsíčně nedostanete ani jedno.
Nevím, co jste nahrával, od UPC mám nesymetrické připojení s 40 Mbps upload se zárukou minimálně 40 %. Centrio má 50 a bez záruky minimální rychlosti. Mimochodem ty jejich tarify, kde uvádějí 100 Mbps, protože přeci 50 down + 50 up je 100, jsou na odebrání licence.
Obávám se, že s konečným řešením bude muset jako vždy přijít Google a to hrubou silou. Něco ve smyslu postupného prosazování výsledků vyhledávače podle dostupnosti na IPv6, řekněme 2 roky, kdy po této lhůtě by přestal výsledky dostupné jen na IPv4 zobrazovat úplně a za dalšího třeba půl roku by pak úplně vypnul dostupnost svých služeb na IPv4. Věřím tomu, že by se věci daly velmi rychle do pohybu a jak poskytovatelé připojení, tak provozovatelé serverů by hodně rychle zjistili, jak se IPv6 používá.
Tím chcete říct, že by bylo dobré vypnout IPV 4 úplně, ale třeba já má 3 Voip brány, které IPV6 neumí to bych je měl i když jsou asi 10 let staré vyměnit? Kdo mě to zaplatí asi pár takových jako vy. Až příjdou, že se připojím s ipv4 na ipv6 a opačně naprosto bez problémů potom ano. A to že se na nějaký web nedostanu pokud by byl jen 6 only asi ani náhodou. jestli ten web zije z reklamy tak určitě si rozmyslí jestli ho většina zobrazí nebo ne.
Na to, aby bylo možné komunikovat po IPv4, musí být dva. Kvůli tomu, že vy máte VoIP na IPv4, nebudou všichni na světě držet VoIP na IPv4. Prostě si před to dáte NAT, do internetu to bude komunikovat přes IPv6 a za NATem si s tou bránou klidně komunikujte děrnými štítky. Vy se sice nedovoláte na žádnou bránu, která bude mít jen IPv6 adresu, ale to je váš problém.
Ten web sice žije z reklamy, ale z té reklamy musí pokrýt náklady na provoz toho serveru. Už dnes je provoz na IPv4 dražší, protože si musíte nějakým způsobem platit veřejnou IPv4 adresu.