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

Hi,

I'd like to add a different perspective. We basically have seven /8s left
(plus the five that will be given directly to the RIRs when we come down to
that number). I think the world expects everybody to be as responsible as
possible with those last available /8s.

Taking a /8 to RFC1918bis space means that it is away from global address
space use. If we want to do that we have to be really, really sure this is
the right thing to do. IETF would really have to have strong consensus on
it.

I seriously doubt we can converge to any consensus before the IANA pool is
empty. 

Just a thought.

Cheers,

Jonne.


On 11/11/10 5:13 AM, "ext 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.

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


-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34
E-mail: [email protected]


_______________________________________________
v6ops mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/v6ops