[arin-ppml] *Spam?* Re: Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack

[Ted Mittelstaedt]

On 12/29/2010 12:46 PM, Jason Schiller wrote:
> On Tue, 28 Dec 2010, Kevin Kargel wrote:
>
> |I must concur with Owen on all points.  I have an IPv6 allocation, and I
> |am fighting hard to get native IPv6 routing from my upstream(s).  The
> |only reason I can see to support 125 would be a completely selfish one in
> |that I have predominantly met the requirements and that it would make the
> |remaining pool more accessible to me because of the number of entities
> |that would be disqualified from accessing it because they have not worked
> |toward meeting the IPv6 requirements.
> |
> |I am not willing to put my selfish concerns ahead of the community.  If
> |it is desired to force one protocol by requiring another protocol as a
> |pre-requisite, then there are more appropriate standards bodies to
> |accomplish that than a registrar.  (IETF?  IEEE?)  I suspect such an
> |attempt within the standards bodies would be rejected out of hand as it
> |should be here.
> |
> |Can you imagine any of the standards organizations accepting a proposal
> |that says interfaces without an IPv6 address must not have an IPv4
> |address?
>
> So over a decade ago IETF decided to make IPv4 and IPv6 incompatible on
> the wire.  This was by design.  This leaves an obvious transition problem,
> how to allow IPv4-only systems to talk to IPv6-only systems.
>
> The IETF supported solution was dual-stack, with the expectation that all
> IPv4-only systems that need to talk to the entire Internet will go
> dual-stack.  Thus as the Internet continues to grow, and that growth gets
> fulfilled by creating IPv6-only networks and hosts, that these
> pre-existing systems will already be dual-stacked and there will not be a
> transition / translation issue.
>

Application-level proxies are also "supported" and always have been.  If 
you telnet from an IPv4 host to a IPv4/IPv6 host you can telnet from
that host to an IPv6 host.  Or you can run a web proxy like
http://www.sixxs.net/tools/gateway/ does.

Ted

> Unfortunately this has not occurred.  I suspect this it primarily due to
> economic factors.  Since there is real cost in deploying IPv6, and no new
> revenue or services, I suspect organizations are deferring the costs for
> as long as possible.
>
> Hopefully people have already done all the analysis, have guessed
> correctly when the industry depletion date is, have correctly estimated
> the cost and time required for such a deployment, have started their work
> in time, and will be ready to embrace IPv6 in a real way when the first
> organizations begin to be forced to fulfill their new growth through
> IPv6-only.  This date is shortly after the frist RIR depletion, possibly 6
> months.
>
> If however this does not happen, then the gap between the IPv4 Internet
> and IPv6 Internet may remain large (as it is now).  As such many of the
> new IPv6-only networks will be unable to reach large portions of the
> Internet.  That gap may take a substantial amount of time to close.  If
> that is the case then we will all be forced to use transition technologies
> like NAT 64&  DNS64 or NAT 46 and DNS46, or lots of layers of CGN NAT4444.
> As the Comcast trial suggests, these technologies have substantial
> performance degradation that customers do complain about.
>
> If a small handful of large providers make a determination that they can
> defer their IPv6 deployment for a few years because they can continue to
> get IPv4 addresses, then this would certainly draw out the transition
> period and increase pain for everyone. This would also likely force their
> competition to seriously consider getting additional IPv4 addresses so
> that they are not at a competitive disadvantage (e.g. their customers can
> only get to the 5% of content on the Internet that is dual stacked).  If
> the majority of a content provider's customer base is IPv4, then much of
> the incentive to move to dual-stack is removed.  New content, or growth of
> existing sites, would require IPv4 addresses as the majority of traffic
> would be IPv4.
>
> I suggest it is good for the community at large to move to providing
> connectivity to both protocols (IPv4 and IPv6) prior to organizations
> being forced to deploy IPv6-only hosts and networks in order to minimize
> the transition pain.  This means all Internet facing  content needs to
> be reachable over both protocols, and any product or service for which the
> need for IP addresses continues to grow needs to go IPv6.  Furthermore
> future content may be deployed as IPv6-only, and as such all pre-existing
> IPv4 networks need to plan to support IPv6 as that content emerges.
>
> Ensureing that all growth going forward supports both protocols sends a
> clear signal that the Internet is ready to embrace IPv6 and is prepaired
> to transition future growth to IPv6-only when necessary.  This is exactly
> the demand the content providers and application developers need to
> justify their investments in IPv6. It also gives people the time to work
> out any issues they have with IPv6, and removes the penelty of being among
> the first providers to be forced into IPv6-only world.
>
> Some have suggested that the pricing of the IPv4 market will solve this
> problem.  The problem with that approach is those that have calculated
> that they plan to purchase IPv4 addresses will still have a long lag time
> to implement IPv6 once they realize that IPv4 addresses are priced above
> the cost of IPv6 deployment, or entirely out of thier reach.  The end
> result is still a long and painful transition / translation period for
> all, and the possibility of slowing or stalling IPv6 adoption.
>
> __Jason
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.