Názor k článku
Vodafone začal s nasazováním IPv6 v mobilní síti od Ondřej Caletka - Normalni NAT nevyrobi to, ze by jednu interni...

Normalni NAT nevyrobi to, ze by jednu interni IP prekladal na 10, 100 nebo klidne 1000 externich, kazde spojeni jinak. Presne tohle vyrabi CGnat.

Nevyrábí. Pokud by to vyráběl, lidem za CGNATem by nehrálo třeba iVysílání. A jak to vím? Protože se mi tak choval NAT64. Takže implicitní tvrzení, že CGNAT střídá adresy, zatímco NAT64 ne, je prostě špatně.

A presne tohle je treba neustale obsluhovat = udrzovat v pameti, prohledavat, a pochopitelne na vsech paketech prepisovat, nejen adresy, ale i porty
To střídání adres naopak algoritmus přidělování adres zjednodušuje. Dohledávání, jakou veřejnou adresu daná privátní adresa používá a hledání blízkého volného portu je náročnější, než jednoduché zahashování parametrů každého paketu a volba odchozí kombinace adresy a portu z celého poolu.

NAT musí adresy v paketech přepisovat, NAT64 musí tvořit zcela nové pakety a řešit spoustu okrajových případů, třeba při fragmentaci, která v IPv6 funguje trochu jinak.

A presne tohle NAT(64) nedela (ne ze by teda nemoh, ale proc by takovou vopicarnu nekdo delal?).

Jestli dělá nebo nedělá, záleží jen na tom, kolik má jeho provozovatel k dispozici veřejných adres a tedy jak moc agresivně je potřeba NATovat. Zrovna nedávno se tady probíralo, že i NAT44 je možné nastavit tak, aby pro každou privátní IP adresu používal pouze staticky přidělenou část portů.

CG slouzi k tomu aby se do maxima a do mrte vycucal potencial moznych spojeni na kazde jedne IP

A ono je to přitom často přesně naopak. Využívat do maxima potenciál možných spojení na každé jedné IP adrese je doménou softwarových NATů, třeba těch implementovaných v Linuxu v domácích routerech. Carrier grade NATy jsou většinou hardwarová zařízení s vysokou kapacitou provozu, ale s omezenou kapacitou na iterativní výpočty. Proto CGNATy často používají mnohem jednodušší algoritmus sdílení adres - třeba Full-cone NAT.