Dual stack IPv6 for IPv4 depletion

Josh Moore jmoore at atcnetworks.net
Sun Jul 5 03:01:06 UTC 2015


But what is the "best compromise" strategy? Dual stack + CGN? Some kind of intelligent 6to4 NAT?




Thanks,

Joshua Moore
Network Engineer
ATC Broadband
912.632.3161

On Jul 4, 2015, at 10:35 PM, Ca By <cb.list6 at gmail.com<mailto:cb.list6 at gmail.com>> wrote:



On Saturday, July 4, 2015, Josh Moore <jmoore at atcnetworks.net<mailto:jmoore at atcnetworks.net>> wrote:
Traditional dual stack deployments implement both IPv4 and IPv6 to the CPE.
Consider the following:

An ISP is at 90% IPv4 utilization and would like to deploy dual stack with the purpose of allowing their subscriber base to continue to grow regardless of the depletion of the IPv4 space. Current dual stack best practices seem to recommend deploying BOTH IPv4 and IPv6 to every CPE. If this is the case, and BOTH are still required, then how does IPv6 help with the v4 address depletion crisis? Many sites and services would still need legacy IPv4 compatibility. Sure, CGN technology may be a solution but what about applications that need direct IPv4 connectivity without NAT? It seems that there should be a mechanism to enable on-demand and efficient IPv4 address consumption ONLY when needed. My question is this: What, if any, solutions like this exist? If no solution exists then what is the next best thing? What would the overall IPv6 migration strategy and goal be?

Sorry for the length of this email but these are legitimate concerns and while I understand the need for IPv6 and the importance of getting there; I don't understand exactly HOW that can be done considering the immediate issue: IPv4 depletion.


Thanks

Joshua Moore
Network Engineer
ATC Broadband
912.632.3161


Yep, dual-stack does not solve problems for eyeball networks. This is why eyeball networks use ds-lite, 464xlat, and map. Each requires some sort of compromise.

At the end of the day, we all need to reject 'direct ipv4', it is an invalid requirement that cannot be supported at scale over time.



More information about the NANOG mailing list