Re: Heads up - Plea for allocating a /8 to ISPs

On Wed, Nov 10, 2010 at 7:13 PM, Erik Kline <[email protected]> wrote:
> Hypothesis: Anything meant to extend the usefulness of IPv4 that does
> not /simultaneously put immense pressure on the thousands of big and
> small things that block IPv6 deployment/ will not result in IPv6
> readiness nor IPv6 deployment.
>
> It may extend the life of IPv4, giving more time for the blocking
> elements to become more IPv6-ready, but how will this time be
> different from the status quo for the last 10+ years?  The only thing
> that could possibly be different is that the free blocks will actually
> be gone by the end of 2011.  But if that doesn't work, it's impossible
> for me to see how these sorts of proposals won't result in anything
> other than "business as usual".
>
> Most animals are motivated to either move toward pleasure or away from
> pain.  Align incentives, or readjust expectations, accordingly.
>

Very stongly agree here.  10 years to roll out IPv6 is a long time.
How is now different from before? At my network, we ran out of IPs in
2007 and tried every trick in the book to try to number users in light
of IPv4 exhaust, RIR rejections, and exponential edge growth.  We had
pain, so we moved.

Only after realizing IPv6 was the only path out of this mess did we
serious take on IPv6.

For the NAT444, LSN, CGN folks. Come on in the waters fine, pick a
bogon up at the door and let your corporate risk management group know
where you are going, they will help you muster up a business case for
real v6 (CPEs for 6rd of whatever).  It's the new normal cost of doing
business with a growing edge.

The good new for the slow to deploy is that IPv4 is not going
anywhere. The sky is not falling for existing users.  There is no such
thing as maintstream IPv6-only content, and wont be for a long time.

Your only concern now is how do you roll out new services and new
users with no IPv4, and now your LSN or your IPv6 plans are tied to
customer acquisition costs and new service enablement cost.  Running
out of IPv4 does not impact business as usual in the near term with no
edge growth, it impacts incremental adds.... incremental adds are now
stuck with a new cost, it pretty standard business case structure to
fund an ipv6 project when framed this way.

Cameron


> On 11 November 2010 11:43, Brian E Carpenter
> <[email protected]> wrote:
>>> I know that some believe that purposely breaking the IPv4 service could be a way to promote IPv6.
>>
>> I don't believe that, and I don't doubt the good intentions of the
>> people proposing this - I've seen too much of them in v6 working groups
>> for that. The problem is elsewhere: this would be a very strong message
>> to ISPs that are *not* actively planning v6 support that here is a way
>> to evade the issue for many more years. So we end up with a bigger
>> legacy of customers stuck behind NAT444 and ISPs that have no intention
>> to move forward.
>>
>> I would like to be proved wrong.
>>
>> Regards
>>   Brian
>>
>> On 2010-11-11 15:30, Rémi Després wrote:
>>> Hi, Ron,
>>>
>>>
>>> Le 9 nov. 2010 à 13:26, Ronald Bonica a écrit :
>>>> I am having a strange sense of déjà vu. About two years ago, we saw another proposal to allocate a /8 for private use to support another transition mechanism. We concluded:
>>>>
>>>> - that we didn't have a /8 to spare
>>>
>>> - Allocating a /8 to ISPs, while it is still feasible, would only slightly modify the date at which IPv4 prefixes er exhausted, not a big deal.
>>>
>>>> - that a /8 wouldn't be enough, anyway
>>>
>>> - ISPs already operate several parallel instances of 10/8 clouds, so that, although a /7 would be more generous than better a /8, a new /8 is enough to replace current 10/8's by a prefix private sites don't uses internally.
>>>
>>> The known reason why ISPs have problems if they assign 10/8's is that some NAT44s:
>>>  . assign 10/8's for internal use
>>>  . cannot work with identical internal and external address spaces
>>>
>>> CONCLUSION:
>>> Assigning a new /8 to ISPs so that they can replace 10/8:
>>> - is easy to do
>>> - has negligible effect on the transition schedule
>>> - does solve a real problem
>>> It should, in view of this analysis above, be highly recommended by IETF
>>>
>>> I know that some believe that purposely breaking the IPv4 service could be a way to promote IPv6.
>>> IMHO, their time would be better spent working to eliminate IPv6 limitations than militating against IPv4 deserved QoS.
>>>
>>> Kind regards,
>>> RD
>>>
>>>
>>>
>>>
>>>
>>>> So, the proposal was abandoned. I wonder if we are not in the exact same place today.
>>>>
>>>> Maybe the equation would be changed if we could make do with a /16, but it appears that a /16 wouldn't help.
>>>>
>>>>                                           Ron
>>>>                                           <speaking as individual contributor>
>>>>
>>>> BTW, the LISP WG is talking about asking for a prefix for a very similar reason.
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: [email protected] [mailto:[email protected]] On Behalf
>>>>> Of james woodyatt
>>>>> Sent: Monday, November 08, 2010 11:50 PM
>>>>> To: IPv6 Operations; [email protected]; [email protected]
>>>>> Subject: Re: [v6ops] Heads up
>>>>>
>>>>> On Nov 8, 2010, at 20:24 , Erik Kline wrote:
>>>>>> Didn't Akira Nakagawa/KDDI present something like this a few meetings
>>>>> ago?  I can't recall clearly...
>>>>>
>>>>> It was in Chicago, if I recall correctly.  At which point Tony Hain
>>>>> joked that we should direct IANA to just turn over the entire remaining
>>>>> free pool for that use.
>>>>>
>>>>> Personally, I'd prefer to take Tony's suggestion as a serious proposal.
>>>>> A single /8 isn't enough, is it?  For NAT444 to be a really workable
>>>>> architecture, we've got to give over enough addresses that service
>>>>> providers can handle at least a hundred million subscriber addresses in
>>>>> the same address realm, right?
>>>>>
>>>>>
>>>>> --
>>>>> james woodyatt <[email protected]>
>>>>> member of technical staff, communications engineering
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> v6ops mailing list
>>>>> [email protected]
>>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>> _______________________________________________
>>>> v6ops mailing list
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>>
>>> _______________________________________________
>>> v6ops mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>
>> _______________________________________________
>> v6ops mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
> _______________________________________________
> v6ops mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/v6ops
>
_______________________________________________
v6ops mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/v6ops