Vlákno názorů k článku Výsledky testování zařízení na IPv6-only Wi-Fi síti od SB - Asi si nerozumíme - proti NAT64 nic nemám,...
-
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ý podporovatelJá 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.
ČLÁNKY DO MAILU