[arin-ppml] ARIN-prop-127: Shared Transition Space for IPv4 Address Extension

[George, Wes E [NTK]]

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Owen DeLong
> Sent: Friday, January 21, 2011 5:18 AM
> 
> That's absurd. If any registry reserves a /10, I'm sure all the
> registries will
> encourage their members to use that /10. To the best of my knowledge,
> there are no plans to submit this proposal to any other registries (and
> I talked to the proposal author about it the day before yesterday in
> person).

[WES] *IF* we consider this policy, it should be a global policy in order to
remove all doubt that this is the intent. I don't like the idea of ARIN
reserving a block and *hoping* that folks from other regions will know about
it and use it. 
> 
> I think in principle, you really can assume that the RIRs are not
> insane
> and won't commit wanton acts of destruction on the community.
>
[WES] Perhaps, but you can't necessarily assume that they will be in
lock-step coordination on this, especially since a similar proposal has
already been shot down at least once in another region. What are they going
to do, ask each applicant "is this for an inside NAT444 pool?" so that they
can redirect them to the shared address space instead of just approving
their request for space? Without any policy mandate to do so? Now who's
being absurd?
 
> On the other hand, what I think you will see if this policy does get
> bogged
> down is a situation where many of the larger providers that are asking
> for this will each go apply for their own allocations and they may or
> may
> not coordinate sharing that with others. I think that is a far less
> desirable
> alternative than getting this policy through.
[WES] As I have said in the IETF discussion, this is sabre-rattling and
empty threats. It's not like some cabal of ISPs has been holding back on
requesting more addresses hoping that this passes and when it doesn't could
show up tomorrow and jointly request enough address space to empty ARIN's
(and IANA's) coffers. If they could justify the space, they would have
already done so, knowing full well that IPv4 address space was about to
become much more difficult to come by. The altruistic angle of this is being
oversold - they're running a business, and if they deliberately put that
business in jeopardy by not getting the resources they need and can justify
while they were available, their employment would be in jeopardy.
Broadband providers *already* have enough IPv4 space for their existing
customers, so they only need enough space for customer growth. Given that
most of them are in the business of providing internet service over a
physical connection, they are limited by the footprint of their service
area, and that growth potential is similarly limited. Even if they grow via
absorption of smaller players, those players should come with some IP
addressing resources. Since this is also a discussion framed by the need to
support *legacy* equipment, the concern about retroactive support for IPv4
is also losing veracity. Greenfield network expansions, or even new customer
acquisitions within existing footprint can't complain about legacy
installed-base that can't support IPv6, meaning that the need for NAT444 is
limited to support for devices in the home that can't support IPv6 - which
should start to become an ever-shrinking number.
The major exception I can think of in this case is mobile providers, who are
seeing a dramatic increase in the amount of data usage in their existing
customer footprint, meaning that their IP address pool oversubscription
ratios keep dropping. However, many mobile providers are already doing NAT44
using either RFC1918 or squatting on Bogon space. So again, we're
oversensationalizing the urgency of this issue.

Wes George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6793 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110121/26f487ee/attachment.bin>