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

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

_______________________________________________
OPS-AREA mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ops-area