On Jun 24, 2008, at 10:23 AM, Tom Vest wrote:
> Hi Owen,
>> Thanks for the question.
> For the most part, the answer was anticipated by Paul.
Yeah, that's one of the reasons I like having Paul on the BoT.
He's quite good that way.
>> If a policy like this gets approved, and the reserved pool is large
> enough to last long enough so that no one -- no active IPv4-based
> operator or outside speculator -- could even conceive of a time
> horizon over which exploitation of the asymmetry/bottleneck
> opportunity might be profitable, then perhaps this won't be a problem.
>I originally proposed a /8. The current proposal is a /10. These
would probably be handed out
as /24-/28 sized chunks, so, I suspect that will at least get us past
the point where others might
be willing to migrate away from some portion of their IPv4 stuff into
other solutions.
> For that, the reserved pool would have to be big enough, at least,
> to accommodate transitional resources for all new entrants, assuming
> the fastest plausible rate of new entry, for the longest conceivable
> transition to de-facto full IPv4-IPv6 substitutability -- the point
> when everything important is transparently accessible by IPv6-only
> networks.
>I think a /8 would provide a comfortable cushion beyond this. A /10
will likely be more
than enough space as well. I think we're talking about a 5 year period
beyond IPv4
exhaustion maximum. This would accommodate at least 16,384 new
provider-independent
entrants during that time, and, likely substantially more, possibly as
much as 256k new
entrants. I believe that is well above any anticipated number in a 5
year timeframe.
> To begin estimating that quantity, I could derive the historical new
> entrant rate for the RIPE region, because I can distinguish the
> initial allocations from the subsequent allocations -- but I would
> have to defer to somebody else for the ARIN, et al rates...
>At this point, the rates are probably relatively similar with RIPE's
rate being slightly
higher.
> In either case, what would count as a plausible new entry rate for
> the next (x) years, relative to the historical rates -- what is the
> biggest bottleneck likely to be (address resources, routing
> capacity, transport facilities, etc.)? And what's the largest
> plausible (x) until de-facto substitutability is achieved, given (at
> least) the strategic considerations above?
>In my opinion x<=5 and max plausible rate is <2000/year with likely
being closer
to 200/year.
Owen
> TV
>> On Jun 24, 2008, at 11:15 AM, Owen DeLong wrote:
>>> Tom,
>> Absent the recent policy proposal to create a reservation
>> for IPv6 Transitional Technologies in the ARIN IPv4 free pool,
>> I would agree with you. However, wouldn't that policy mitigate
>> what you are saying below? (assuming it gets adopted)
>>>> Owen
>>>> On Jun 24, 2008, at 6:55 AM, Tom Vest wrote:
>>>>> There is also the matter of asymmetrical dependence and bargaining
>>> power (detailed ad nauseam last week).
>>>>>> Unless something changes, on the day after free pool exhaustion and
>>> every day thereafter, "incumbent" IPv4-based networks will be able
>>> to
>>> unilaterally decide whether/when they want to be transparently
>>> interoperable with native IPv6 networks, and they will be able to
>>> unilaterally act to make that possible, e.g., by going dual-stack,
>>> renumbering, or operating a symmetrical 6/4 gateway.
>>>>>> Unless something changes, on the day after free pool exhaustion and
>>> every day thereafter, new IPv6-only networks will need to
>>> interoperate
>>> with the universe of incumbent IPv4 networks. However, they will NOT
>>> be able to unilaterally act to make that possible as long as that
>>> requires at least some IPv4, which at that point will only available
>>> from those incumbent networks, or from "pure speculators".
>>>>>> That asymmetry is what will drive the price of IPv4 up and up, and
>>> that increasing profit potential and bargaining power -- which is
>>> just
>>> an artifact of the lingering IPv4 bottleneck between new IPv6
>>> networks
>>> and everything still accessible only via IPv4 -- is what will
>>> incentivize incumbent IPv4 networks/IPv4 dealers to delay their own
>>> shift to transparent interoperability for as long as possible.
>>>>>> Aspiring to be the last-mover will be the only rational strategy in
>>> the environment that an IPv4 resource transfer market will create.
>>>>>> But maybe rationality will take a holiday :-\
>>>>>> TV
>>>>>> On Jun 24, 2008, at 9:21 AM, Kevin Kargel wrote:
>>>>>>> Don't forget the fact that IPv6 is not yet a perfect or mature
>>>> service.
>>>> Delaying IPv6 implementation will avoid the costs involved with
>>>> development and debugging of local networks while letting others do
>>>> the
>>>> dirty work. I am not advocating this, just recognizing a reality.
>>>> The
>>>> forward thinking administrators that want to make a difference in
>>>> the
>>>> world will jump in and get it done, the profit driven enterprises
>>>> will
>>>> sit back and wait until everything is easy or unavoidable.
>>>>>>>>>>>> -----Original Message-----
>>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-
>>>>bounces at arin.net]
>>>> On
>>>> Behalf Of Lee Dilkie
>>>> Sent: Tuesday, June 24, 2008 6:44 AM
>>>> To: michael.dillon at bt.com>>>> Cc: ppml at arin.net>>>> Subject: Re: [arin-ppml] Q1 - ARIN address transferpolicy:
>>>> whythetriggerdate?
>>>>>>>>>>>>michael.dillon at bt.com wrote:
>>>>>> As with many other technologies, there is a substantial last-
>>>>>> mover
>>>>>> advantage to going dual-stack or single-v6.
>>>>>>>>>>>>>>>> On what do you base this opinion?
>>>>>>>>>> --Michael Dillon
>>>>>>>>>>>>>> Moore's Law, one would think. Delaying purchase of networking
>>>> equipment
>>>> will yield better performance for lower cost.
>>>>>>>>> _______________________________________________
>>> 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 the ARIN Member Services Help Desk at info at arin.net>>> if you experience any issues.
>>