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

[Owen DeLong]

On Dec 29, 2010, at 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.
> 
People keep saying decided as if there was a choice. The reality is that
we needed more bits for addressing. It's very hard to put 128 bits into
a 32 bit field. IETF decided this was too hard and any efforts to do so
had proven unsuccessful and cumbersomely complicated.

It's really not much of a decision so much as a reality.

> 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.
> 
Which was and is a perfectly reasonable design.

> 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.  
> 
Partially economic factors, partially the 10-Q based culture we have
evolved in the US and that the rest of the world has followed our lead on.
(10-Q is quarterly SEC filing, basically a publicly traded companies
quarterly report).

As such, since IPv6 hasn't been needed next quarter yet, few have put
it on the priority list for this quarter.

> 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 they had, we would have a much larger number of organizations
much further along in their IPv6 deployment process and there would
be no such thing as a product that still sells without IPv6 support.

> 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.  
> 
Yep.

> 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.
> 
No matter how you slice it, that model cannot be sustained much longer.
New IPv4 addresses for content cannot continue as long as some people
seem to think may be possible.

> 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.  
> 
I agree with you that such a move is good for the community.

> 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.
> 
While this is a true statement, I don't think this will be any clearer a signal
than the letters that were already sent to resource holders, the public outreach
that has been done, the front-page article on CNN.COM, and various
other signals that have been sent.

I'm not seeing how this requirement accomplishes any of the other things
you say beyond sending a signal.

> 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.  
> 
A somewhat long and very painful transition is, at this point, inevitable.
As I have said, we're too far up the canyon. There is no room to turn
the plane. Our remaining choices are to make the best landing we can
relatively straight ahead, or, attempt a radical maneuver which will
end in one of the following ways:
	1.	Plane strikes cliff with a direction of travel perpendicular to
		the cliff wall. (small impact site, wreckage relatively contained)
	2.	Plane stalls and hits bottom of canyon in near vertical attitude
		(small impact site at bottom of canyon, wreckage relatively
		contained)
	3.	Plane strikes canyon in a wing-low attitude closer to
		parallel to the canyon wall, likely cartwheeling and
		breaking up on impact. (wreckage widely scattered,
		large impact zone)

While none of these are good options and the desire to make a
radical maneuver becomes nearly unavoidable reflex as the canyon
wall approaches, landing straight ahead offers the highest
survival rate.

We are about a year past the point for making any such radical
turn with any hope of success.

Owen

> __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.