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

Jason.Weil at cox.com Jason.Weil at cox.com
Fri Oct 30 10:22:17 EDT 2009


I agree with Mike.  

As Tony Hain has already pointed out RFC4864's details for Local Network Protection is a great start. If Address Autonomy feature of 4864 does not solve the problem which is what is sounds like some in the enterprise space claim is needed then look at Address Independence as being specified in draft-mrw-behave-nat66-02. This IMO at least is a much better way to offer provider independence in the enterprise than what is done today with NAT44.

Just for the record I firmly believe that NAT needs to be removed from the home network.  RFC4864 in addition to GUA space when connected to a service provider offers a much richer solution in this environment. 

Jason

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michael K. Smith
Sent: Thursday, October 29, 2009 11:48 PM
To: Chris Engel; 'Lee Dilkie'
Cc: 'arin-ppml at arin.net'
Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern

Chris:

You obviously have very strong opinions about +NAT, as many have strong
opinions about -NAT.  This is not the right venue to jump on that particular
soap box.  Might I suggest you take your arguments to the IETF?  That's
where these decisions are being made.  In my opinion, ARIN is not going to
be able to change your opinion about the usability of IPv6 in its present
state based upon any updates to the NRPM.

The v6ops group might be a good place to start.  See
http://www.ietf.org/dyn/wg/charter/v6ops-charter.html.

Regards,

Mike


On 10/29/09 11:56 AM, "Chris Engel" <cengel at sponsordirect.com> wrote:

> Lee,
> 
> I'm not sure it's that simple. If the corporate network admins don't role out
> some sort IPv6 stack internaly (and probably some software upgrades too) then
> how would thier end users reach any IPv6 only site?   If IPv6 isn't bound to
> the end users NIC cards....how are they going to get to an IPv6 only site?
> 
> I assume that means there has to be some sort of IPv6 network created
> internaly....even if it's not really used for much else.
> Furthermore....knowing what I do about the speed of adoption of client
> software and OS in the corporate world....I am assuming that there will likely
> be some need for upgrades of certain client software in order to work with an
> IPv6 address as a destination.
> 
> Furthermore, if there is alot of resistence to such implementations.... who,
> on the other side of the equation is going to want an IPv6 address....if it
> means that alot of people aren't reaching it?
> 
> I can't see many businesses on the other side of the equation jumping through
> hoops to impliment an IPv6 address if they think a good chunk of people won't
> be able to access it. Frankly I'd see them more likely jumping through hoops
> to make thier existing IPv4 addresses work....or find a way to obtain more in
> some sort of after market.
> 
> Maybe if you get some important early adopters willing to take the risk to go
> IPv6 address only (which is going to be a tall order in itself)...you can
> force the hands of the rest of us to come along and put in support for it
> localy, probably kicking and screaming.... but it's going to be an UGLY, UGLY
> scene.... if there aren't some serious efforts to address the legitimate
> concerns raised.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Christopher Engel
> 
> -----Original Message-----
> From: Lee Dilkie [mailto:Lee at Dilkie.com]
> Sent: Thursday, October 29, 2009 12:49 PM
> To: Chris Engel
> Cc: 'arin-ppml at arin.net'
> Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern
> 
> 
> Sorry for top-posting but it's not important to answer your concerns on a
> point by point basis.
> 
> I've heard this from a lot of IT admins and even from my own company's IT
> admins.
> 
> But the fact is, you are not the problem. Companies, like yours, do not use
> all that many v4 addresses today. They have nice, profitable, v4 address
> blocks from an ISP and are well managed entities. You can stay with v4 for a
> very long time.
> 
> No, I think what we're after is getting the major consumers, ISP's for public
> consumption, to move dual then eventually v6 only. And for that, all we need
> is to get a good number of the servers they connect to, to go dual stack.
> 
> And yes, while you'll still be running v4 inside and using some small v4
> public address block, you'll very likely run dual stack on your public
> internet-facing servers to allow the new "v6 only" customers to see your
> wares. And that effort is a *lot* easier and cheaper than rolling out v6 in
> your entire enterprise.
> 
> -lee
> 
> Chris Engel wrote:
>> 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.
>> 
>> 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.
>> 
> _______________________________________________
> 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.

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



More information about the ARIN-PPML mailing list