[arin-ppml] IPv4 Depletion as an ARIN policy concern

[lar at mwtcorp.net]

I've tried to be quiet but I can't any more. Sorry
> 
> I'm going to be very upfront with you guys. Without confidence that 
>something very similar to NAT will be available for IPv6.... I'm going to 
>eschew any adoption of IPv6 on the networks I'm responsible for. I guess 
>that would also entail...grabbing, hoarding and stockpiling as many IPv4 
>addresses as possible that might be required for future use.
> 
> If you think my reaction is atypical for the Network/System/IT admins on 
>corporate side end user networks.... I think you are going to be in for a 
>rude awakening. You are going to start seeing alot more of this type 
>behavior as awareness of the details of IPv6 increases in that population.
> 
> 
> The number one way to INSURE resistance to the adoption of a new 
>technology is to REMOVE FUNCTIONALITY that people already enjoy under their 
>existing functionality. I believe that is the exact opposite reaction 
>toward IPv6 that most people on this list would like to see occur.
> 
> It is pretty much IRRELEVANT that some people find NAT problematic or 
>unusefull. Those of us who do rely on it...and there are many...obviously 
>find it useful.

<Two Soapboxes high>
I hate to say this but I'm exactly on the opposite side. NAsTy has
been so broken with so many different implementations many of which
cause great harm that the end of NAsTy is the greatest single advantage
I see in IPV6. Those of you that are proud of your NAsTy implementation
don't sit in the seat of those of us that have to spend valuable
time and resources trying to keep things working.

If IPV6 is to have NAsTy then the engineers need to lock it down so that
applications can tell what and how many NAsTy boxes were in the path
and demand that they leave the payload be AND their should be a place where
those of us that have to deal with the effects of it can bill those of you
that love it for our time and trouble.

OR everyone could just use the methods that have been engineered into IPV6
to make IPV4 type NAsTy unnecessary. I wonder if we don't have a bit of a
"I won't buy a car until they make a place to hook my horse onto it" thing
going on here.
<Stepping Down from Soapboxes>

A lot of very big names have servers behind NAT that causes customer 
problems
and they don't even know it because the customer call's their ISP and 
complains
instead of calling MR.BIGGUY.

> 
> On the other hand....the best way to promote the adoption of a new 
>technology is to make transition to it as SEAMLESS as possible....meaning 
>the absolute MINIMUM number of changes in end user behavior or 
>functionality required to make it work.
> 
> IPv6 has ZERO utility for me other then the possibility of allowing a few 
>more public addresses if I need them. Changing the abstraction of my 
>internal network would actually be a significant NEGATIVE. Changing 
>fundamentally the design architecture on my internal network and the 
>operating procedures necessary to manage it would be a significant 
>NEGATIVE. There would already a HUGE amount of work and cost involved in 
>just setting up the ability for end users to connect to IPv6 
>addresses....for frankly NEGLIGIBLE benefit (at least initially).
> 
> There is already a fairly strong chance that the initial adopters of IPv6 
>only addresses are going to be balkanized from many existing (IPv4) sites 
>due the cost/benefit ratio of implementing IPv6 for many organizations. 
>Placing more hurdles and disincentives then are necessary for Network 
>Admins to support interoperability with IPv6 sites on thier networks is NOT 
>going to help that.
> 
> 
> That's all I'm saying. Whether ARIN's role or policies would effect that 
>equation.... I would have no clue. Certainly anything policy wise that 
>would bar or preclude some sort of IPv6 NAT adoption would be 
>detrimental.... and certainly being aware of such issues/concerns in it's 
>planning in regard to IPv6 would be helpful...I would think.
> 
> 
> 
> Christopher Engel
> _______________________________________________
> 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.

Larry Ash
Network Administrator
Mountain West Telephone
400 East 1st St.
Casper, WY 82601
Office 307 233-8387