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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cameron,

On 11Nov2010, at 14.58, Cameron Byrne wrote:

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

We are deadly serious on IPv6, you must not have listened to the discussion.

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

Wonderful idea - corporate risk management assisting with IPv6 transition - I though we had problems....
> 
> 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.

We already have that business case done, and have been executing on it.

> 
> 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
>> 
> _______________________________________________
> OPS-AREA mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ops-area
> 

- ---
李柯睿
Check my PGP key here:
https://www.asgaard.org/~cdl/cdl.asc

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJM22/pAAoJEGmx2Mt/+Iw/R3oH/2BLkOEDH9rY83EljcwCz+IO
QJ4TmhQs4P/TaXXLO47m5zUqqNQF1VETP4k5TU1JV/WJ8vPpiUifHJjgm8dee8vG
rMM/gN6gCAV89+91RKDQhxFbjrfyBcjgkJ8PkSZbccY772LxO8wkwvnO5smtJHVj
hHC6TnP28j1CU8ZzSDPoLUppxHo7RqyYdtEQImSqmuqulXe8kgUmXm2erOm/myS8
7Rnvm9O0G6ZXqse4+Xp2NUp344d0VmagjcixOdkSer7Q5xmIJMVH3JpZ6TXE1xON
pI/EiYygwM8vPhaymQmtCsVbK+gsoKY1yEMtroc4lSCUGjfiu7xD8Fp40bqzziU=
=H1UB
-----END PGP SIGNATURE-----
_______________________________________________
OPS-AREA mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ops-area