As I said, <i>application</i> programmers just using TCP have way less to deal with than all the other hardware in the stack. The point is all the <i>other</i> hardware has much larger changes to make than just &quot;extending an address&quot;. It&#x27;s a brand new protocol, not an extension.<p>I&#x27;ve been involved in some relatively <i>trivial</i> extension of application-level network devices to IPv6, and even <i>that</i> was a surprisingly large nightmare because you embed all these assumptions about addresses everywhere without even realizing it. Not just &quot;they&#x27;re a 4-byte integer&quot;; one big one you embed without even realizing it pretty deeply is that &quot;A network address is <i>one type</i>.&quot; In dual-stack code, you no longer have &quot;an address&quot;. You have two types. That&#x27;s just an example of the problem.<p>I think perhaps anyone who is opining on how easy this should be should also mention whether or not they&#x27;ve tried to convert an application or a network device to IPv6 or not, because I&#x27;ve seen even within a network company a lot of severe underestimations of the difficulty. (Some of these things are much easier when you write new code for IPv4+IPv6, which is why I say <i>convert</i>. Of course if you write new code on an abstraction layer that already solved this problem it&#x27;s easier.) IPv6 <i>is not</i> IPv4, quite profoundly. It&#x27;s not just addressing changes. Converting to IPv6 <i>is not</i> just &quot;replacing all your gear&quot;, it is <i>rewriting foundational aspects</i> of all that gear and a non-trivial amount of the software that uses it. Not mere surface aspects like addressing schemes.<p>This all looks fine and dandy from 30,000 feet, but when you&#x27;re on the ground, it&#x27;s a really hard transition.