Názory k článku Výsledky testování zařízení na IPv6-only Wi-Fi síti
-
Moc tomu nerozumim (neregistrovaný)
Prosím vysvětlete mi to někdo jako programátorovi i klientů i serveru.
Server má otevrenej port na IPv4 i IPv6. DNS záznam mám A i AAAA
Klient k nalezení serveru používá getaddrinfo.
Tohle používám už hodně dlouho. Proč bych měl nějak uzpusobovat program nějaké technologií cpát xlat whateverlat? Co tam vlastně dělá?
-
Ondřej CaletkaZlatý podporovatelV tomhle případě se nemusíte o nic starat. Ten problém nastává, když máte server jen na IPv4 a/nebo v DNS jen A záznam. Pak jde často o mylný předpoklad, že když máme server jen na IPv4, nemusíme na klientovi řešit IPv6, takže otevřeme přimo socket s AF_INET a radši ještě do aplikace zadrátujeme přímo IPv4 adresu. To pak na IPv6-only síti selže. Hezky je to rozepsáno v odkazovaném blogpostu Spotify.
-
Pavel (neregistrovaný)
Tak se zkuste zamyslet, co to znamená přidat do databáze jeden sloupec.
Jako elév jsem takto přidal při vývoji nové verze SW do databáze jeden sloupec, a to byl mazec. Zákazník měl databázi dost velkou a upgrade na novou verzi SW pro něj znamenal třídenní výpadek!
Ano, při programování se opravdu musí myslet.
-
j (neregistrovaný)
Trotl jako ty s mozkem v prdeli si neumi ani precist na co reaguje ze? Kdyz mas aplikaci 10+ let starou, tak zadnej sloupec nikam nepridas, protoze bys ji nejdriv musel celou prepsat, zadarmo, protoze platit ti za to nikdo nebude. Tak maximalne ti sdeli, ze tvuj vytvor nefunguje. Ono se to totiz do ty databaze nedava vetsinou jen tak z prdele aby to tam hnilo, ale nejak se to nekde dal pouziva.
A jak zminil Pavel o post vedle, zmena struktury databaze muze vyvolat potrebu desitek hodin udrzby.
-
Petr M (neregistrovaný)
Pokud je appka 10 let stará, to furt běží na 10 let starým železe? Tak se to mělo řešit při upgrade. S novým železem se hodí i nová instance DB. Přemigruje se s doplněním sloupce, otestuješ, swapneš a nazdar...
Akorát furt nevím, na co je které aplikaci sbírání IP adres do databáze.
1. Pokud jdou to servery, najdeš je v DNS a nemusíš si je syslit.
2. Pokud jsou součástí kontaktních údajů, je na čase tu tabulku zeštíhlit tak jako tak.
3. Pokud je to kravina ve stylu komentářů od iinfa, viz bod 2 nebo natvrdo nějaká fejknutá IPv4 a hotovo.
4. Pokud je to u ISPíka na evidenci pro benga, tak ať prostě natvrdo přiřadí prefixy (nepotřebuje sledovat CGNAT v reálným čase) a je klid.
5. Pokud je to blbina typu Skype, tak stejně dřív nebo pozděj bude muset migrovat. Pokud na to 10 let kašlou, tak si svůj osud zaslouží. -
j (neregistrovaný)
Hele a staci ta tvoje jedna mozkova bunka na to, ze sit != web? Tys vzivote nevidel ani garazovou firmu, natoz cokoli nad 1 samozamestnance.
Takze aby si tvoje bunka udelala predstavu, jen nasazeni nove verze SQL (bez zmen SW) = 1/2 roku priprava (mala firma), celkem 14 dnu realizace (nikoli v kuse, ale postupne se migrovaly jednotlive databaze jednotlivych systemu, umyslne a proto, aby se to kdyztak nepodelalo vse najednou) a dalsi mesic az dva vychytavani musek, protoze za roky provozu a ruznych uprav se vzdy najde neco, co nikdo nikam nenapsal.
Ty nemas ani paru o tom, ze firma muze mit klidne i miliony zarizeni, ktery provadeji nejakej reporting - cidla/ridici jednotky/.... a kupodivu, zazracne se k jejich identifikaci pouziva prave IP ... a ten SW kterej to obsluhuje muze bejt klidne i 30 let starej, a v databazich muzou bejt za tech 30let data. Data ktery se pouzivaj, protoze se trebas statisticky vyhodnocujou.
Zase, pro tvoji mozkovou bunku nepochopitelny - rekneme ze nekde naroste zmetkovitost, a pritom se "nic" nezmenilo, ale z tech historickych dat se zjisti, ze je v dany casti narust vlhosti
Ale jo, ucite kdyz do takovy firmy pribehnes, a rekne "voe kup novy kramy (za par miliard) a se to stim splachne (za dalsich par $$$)" tak managorstvo zasalutuje a rekne "jasne voe, dem do toho".
-
Plojhy (neregistrovaný)
Na semináři IPv6 jsem byl a testů jsem se účastnil s počítačem s Windows. Mám telefon s Windows 10 Mobile, ale ten IPv6 vůbec neumí proto není v testu. Po připojení k síti mi to psalo "bez internetu" a nedostal jsem IP adresu. Nebylo to pouze u mého telefonu s W10M, ale zkoušel jsem to ještě u kolegy. Úplně bych tedy netvrdil Váš nadpisek "Pro mobilní zařízení je IPv6-only realitou" :)
-
Migilenik (neregistrovaný)
A to bylo keců že se NAT64 používat nebude. Když si vzpomenu, jak pointou IPv6 bylo zabít NAT, a teď máme NAT64 a k tomu xlat. Jo holt když teorie narazí na praxi.
A jen tak mimochodem... Co se stalo s proklamovaným dualstackem. Vždyť ten měl zabránit potřebě takových ke krásných překladu adres.
-
Jenže NAT64 je přechodový mechanismus pro situace, kdy máte k dispozici jen IPv6 síť a potřebujete přistupovat i ke starému IPv4 internetu. Jeho smysl i princip je úplně jiný než u klasického NAT. Nešetří adresy, jen bezestavově překlápí dva druhy adres (v4 internet je celý ukrytý v části v6 rozsahu).
Dual stack samozřejmě funguje, ale znamená starat se o dvě sítě. Já osobně bych už dávno jel IPv6 only právě s NAT64. Brání mi v tom některá zařízení jako televize, IP telefony nebo čtečky knih. Kvůli nim musím jet dual stack, protože bez IPv4 adresy si na síti neškrtnou.
-
Ondřej CaletkaZlatý podporovatel
Určitě je. Ta zásadní výhoda NAT64 proti všem ostatním IPv4-as-a-service přechodovým mechanizmům je v tom, že pro drtivou většinu případů nepotřebuje na straně koncového zařízení žádnou úpravu a to ani pro přístup k IPv4-only serverům. CLAT řeší opravdu jen velmi okrajové případy, které se jinak dají mnohem elegantněji vyřešit způsobem, jaký nastolil Apple.
Proti tomu všechny technologie postavené na tunelování vyžadují, aby koncové zařízení vytvořilo patřičné tunelové rozhraní a veškerý IPv4 provoz jím směrovalo. Což může fungovat třeba u CPE, která dodává ISP, ale těžko to může fungovat třeba ve veřejné Wi-Fi síti, kde provozovatel netuší, která zařízení se připojí.
-
ZP (neregistrovaný)
IPv6 only by mělo být IPv6 only. Žádný DS, žádný XLAT, žádný NAT64, prostě IPv6 only. Tyhle berličky šestce neprospívají, ale pouze škodí, nikdy ta implementace není čistá, vždycky z toho vyleze paskvil, roste komplexita, je s tím výrazně více práce a tlak na nasezení IPv6 jinde to také snižuje.
-
Petr M (neregistrovaný)
"Žádný DS, "
DS = 4 a 6 soušasně != IPv6 only"žádný XLAT, žádný NAT64"
To je jenom přechodový mechanismus, není to standardní součást
"Tyhle berličky šestce neprospívají, ale pouze škodí"
Díky nim se dá nasadit šestka i v prostředí, kde jsou aplikace jako Skype apod., který na 6ce nejedou. Jak uškodí, když může zákazník při nasazení 6ky dál provozovat to, co 6ku neumí? V první fázi je přece potřeba dostat 6ku nativně k většině uživatelů, teprve ve druhé fázi se dá zařezávat 4ka. A první fáze nikdy neproběhne, pokud koncákům některý věci nejedou...
-
Ondřej CaletkaZlatý podporovatel
Tohle velice snadno vyřeší poddimenzování přechodových mechanizmů. Když bude DS-lite AFTR přetížený (což se třeba v Německu údajně pravidelně stávalo), služby dostupné po IPv6 to nijak neovlivní, ostatní budou mít problém.
-
SB (neregistrovaný)
Caletka:
Možná to obecně není tak špatný nápad. Prostě omezovat finance do infrastruktury IPv4. Síťovou neutralitu to neporušuje, protože uživatel se sám rozhodl, že chce využít spojení přes IPv4 (tj. jeho infrastrukturu a vše, co to obnáší), přestože poskytovatel nabízí i 6. Dokud dimenzování dostačuje pro dosažení garantované rychlosti, nemůže poskytovatele nikdo prcat. -
Ondřej CaletkaZlatý podporovatel
Jak můžou berličky jako DS, XLAT, či NAT64 šestce škodit? Vždyť je to jen způsob, jak po šestce přenášet IPv4 provoz, když ho z nějakého důvodu přenášet potřebujete. Pokud IPv4 provoz přenášet nepotřebujete, IPv6-only síť funguje jako taková a to, jestli v síti jsou nebo nejsou nějaké přechodové mechanizmy vás vůbec nemusí trápit, protože to na přenášení nativního IPv6 provozu nemá vůbec žádný vliv.
-
To je teoretická odpověď a pohled zpět na posledních 10 let ukazuje, že je to přesně naopak. Dokud se neobjevily tyhle ty mechanismy, IPv6 každý ignoroval.
Po bitvě je každý generál, ale řekl bych, že právě největší chybou při počátečním návrhu IPv6 byla chybějící schopnost komunikace s IPv4 sítěmi. Sice by to ztížilo počáteční implementaci, ale chybějící interopabilita úplně zmrazila implementaci IPv6 na klientech. A bez klientů nejsou ani servery.
-
Ondřej CaletkaZlatý podporovatel
Vlastně by asi klidně mohlo: https://docs.google.com/spreadsheets/d/1ewf9URWAslwtEFkW_jHWdXwHufdFFHQKxsFd6fDXUOA/
-
SB (neregistrovaný)
Asi si nerozumíme - proti NAT64 nic nemám, je to jediný způsob, jak se můžou spojit 2 různé verze IP, s tím se nic jiného dělat nedá, to je vyřešená věc.
Jde mi o to, zda se vůbec vyplatí použít 464, které z podstaty zasahuje do paketů a přitom vyžaduje SW na straně klientu i serveru, když můžu použít tunel, který taky potřebuje SW na obou stranách, ale nepotřebuje kvůli tomu upravovat pakety. Představoval bych si něco jako IP in IP (jako IPv6 Encapsulation, ale opačně a obecněji), to by mohlo být velice triviální a obecně použitelné.
K druhému odstavci: V tomto se nijak 464 a tunel neliší, požadavky na SW jsou na obou stranách (jak jsem psal výše) - jestli vyrobím v Androidu rozhraní tunelu, nebo rozhraní pro IPv4, za kterým je CLAT, je buřt, oboje musím dodělat. -
Ondřej CaletkaZlatý podporovatel
Já plně souhlasím s tím, že použít tunel místo dvojice překladů tam a zpět by určitě bylo čistější řešení. Ten zásadní problém tady ovšem je – a tahle malá anketa na to poukázala – že pořád spousta zařízení CLAT nepodporuje. A podobně by to bylo i s jakoukoli jinou technologií vyžadující úpravu koncového zařízení. Rozdíl složitosti CLATu a IPIP tunelu nehraje žádnou roli. Jak jsem již napsal, 464XLAT tady má tu výhodu, že i když nefunguje a uplatňuje se jen jeho síťová část, pro uživatele je připojení stále více-méně použitelné.
-
SB (neregistrovaný)
Omlouvám se, můj kořenový příspěvek patřil pod Váš z 12:11, ale to jste asi zjistil.
V souvislosti s tématem si dovolím připomenout svůj názor, že dokud nebudou v internetu obecně využitelná překladová místa a konce tunelů (tak jak byly dosud opačné tunely 6 v 4), které by ulehčily poskytovatelům přechod na 6, poskytovatelé nijak výrazně pr-delemi hýbat nebudou.
-
Ondřej CaletkaZlatý podporovatel
Mikrotik pokud vím nepodporuje ani NAT64 ani DNS64, takže tak jednoduché to nebude. Na vyzkoušení můžete jednoduše vypnout IPv4 a nastavit rekurzivní DNS server na jednu z veřejných testovacích NAT64/DNS64 instalací. Nastavení IPv6 DNS serverů je trochu oříšek, ale nějak se to dá. Pokud chcete vlastní NAT64/DNS64, pořiďte si nějaký router s OpenWRT/LEDE a postupujte podle návodu pro Turris.
-
Ondřej CaletkaZlatý podporovatel
Ano, to je pravda, proto bylo v dotazníku uvedeno: „Vypněte případné akcelerátory, případně použijte anonymní režim.“ Jestli to však všichni poctivě udělali, se asi nedozvíme.
-
Jsem momentálně Androidem připojen k WiFi, která jednoznačně IPv6 nepodporuje a přesto na adrese http://test-ipv6.cz mám hodnocení 10/10. Je to způsobeno tím, že mám v chromu aktivní úsporu dat. (Která je aktivní i při použití WiFi).
Bylo toto zohledněno v testu/výsledcích na semináři?
ČLÁNKY DO MAILU