[arin-ppml] New Entrants shut out? (Was: ARIN-2011-5: ... - Last Call

[Ray Hunter]

Sorry my wording was maybe rather unfortunate. Let me try to rephrase.

I actually explicitly support the ARIN last /8 policy precisely because 
it acknowledges that "business as usual" cannot carry on ad infinitum, 
and attempts to fairly allocate the few remaining addresses, and 
protects new entrants from large incumbents. But it does mean that new 
entrants in AP will have a difficult but perhaps ot impossible time, as 
they can only obtain a single /22 allocation. Ever.

I did some analysis that attempted to filter recent APNIC allocations 
made to new market entrants (those organizations obtaining one ASN 
record and one IP block in 2011)

I found the following allocations (although there may be some errors 
here as it was my custom PERL code filtering and joining public whois 
data published by ARIN). I know who these allocations were made to (via 
whois), but have kept the data anonymous.

number of addresses in allocation - number of organizations obtaining 
precisely one new ASN and one new IP block in calendar year 2011 to date
* 256 - 34
* 512 - 7
* 1024 - 35
* 2048 - 12
* 4096 - 4
* 8192 - 6
* 16384 - 2
* 32768 - 2
* 65536 - 3

total105 allocations

The current available allocation now that the last /8 policy has kicked 
in is a single /22 or 1024 address, with no possibility of repeat.

Bear in mind these are just the subset of organizations that have 
already gone to the trouble of obtaining a new AS number in calendar 
year 2011 (which is a pretty stringent test in what they intend to do 
with their internet = evidence that they consider IPv4 internet as 
business critical and demonstrating their intention to multihome)

So in summary, there would appear to be 29 pretty large organizations in 
APNIC who obtained AS numbers and their initial network allocations in 
the year to date 2011, whereas as of today, those requests could no 
longer be honored.

That to me means these 29 organizations would today effectively be shut 
out, because they couldn't even get their minimum requirement for today. 
Smaller allocations are possible, but may not be practically large 
enough for a new entrant. Who really knows? But it is an indication of 
how serious the situation already is. ARIN should realise that they are 
rapidly approaching the same situation, and should think carefully about 
what they consider a "fair policy" for the few remaining addresses.




Meanwhile the (IMHO rather speedy and perhaps even wreckless) allocation 
of a full /10 to existing large ISP's specifically for use for NAT444 
hastens the day when ARIN will no longer have a large block of addresses 
to allocate for other purposes and for allocation via that "fair" policy.

Will these NAT444 /10 addresses also be available for use for a new 
entrant who wanted to implement the newly published stateful NAT64 RFCs 
(6144 through 6147)?

No, they won't, because they will no longer be globally unique.

If ARIN were to adopt a similar policy to APNIC for the remaining 
addresses: that /10 range that is currently proposed to be used for 
NAT444 (for incumbents) could service 2^12 new entrants with a /22 
allocation each for use e.g. with stateful NAT64 [difference between a 
/10 and a /22], or 2^10 entrants running a /20 allocation on the outside 
pool of their NAT64.

So allocating a /10 to NAT444 may be depriving new entrants (who are 
keen to deploy IPv6 networks) from an extremely valuable resource that 
they'd need to deploy NAT64.

I think most people would agree that anyone deploying a native IPv6 
network, together with a transition mechanism so that these large 
numbers of native IPv6 nodes can continue to communicate with a few 
legacy IPv4 servers on a global basis, is preferable over supporting a 
limited sticking plaster to allow a few nodes to speak a few protocols 
in a limited geographic/ISP area for a limited time on IPv4 (which is my 
view of the limited upside of NAT444 compared to say NAT44/DS-Lite).

So what I'm arguing is that ARIN allocating a /10 for NAT444 might make 
things worse for new entrants.

Incumbent providers have had many years to sort out their own problems, 
and IHMO ARIN should not be giving them preferential treatment over 
people who want to deploy native IPv6, but who need a few IPv4 addresses 
for backwards compatibility.



I would also argue that RFC1918 or address swapping would also present a 
possible viable path to NAT444, without the need for making a new 
dedicated /10 allocation.

RFC1918 allocated huge address space for private use. The 10.0.0.0/8 
network alone is far bigger than the requested allocation.
I see no evidence or reason whatsoever to believe  that the industry and 
end users will behave any differently/better with the new /10 than they 
have done with the 10/8 allocation.

The argument made for the need for the new /10 allocation was that 
network 10/8 is in use on some end user gateways.

Well IMVHO if people are really so attached to IPv4 and double NAT 
they'll either be prepared to accept a limitation on the RFC1918 IPv4 
address on their local network (which isn't a huge change relatively 
speaking) or the ISP can split their NAT444 into two clouds: one for 
users with 10.0.0.0/8 on the local network and one for users with 
172.16.0.0/12 on their local networks. These two clouds could then run 
NAT444 independently of each other. Why does an ISP or gorup of ISPs 
require a single NAT444 cloud? [the implementations of NAT444 that I 
have seen support this via the use of alternate VRF's]

After all, the NAT444 proponents are already arguing that everyone is 
going to have to renumber their outside Internet facing interface or 
not? Otherwise how will they reclaim the existing address space for use 
elsewhere? That also means significant disruption to the end user. So 
asking them to renumber their internal network might not be the show 
stopper that some imagine.

On the other hand, if the ISP's are are not going to renumber the 
external interfaces, where is the upside for ARIN for giving away these 
new /10 addresses if it does not free up existing allocations? In that 
case, these new NAT444 users will anyway be new deployments and it would 
be perfectly reasonable to state to a customer that they must not use 
e.g. network 10/8 on their internal LAN and that they need to override 
their default DHCP server range in their own router, which is certainly 
not a big change (compared to the huge changes NAT444 will bring)

In the third option, if the ISPs really are truly desperate to implement 
this technology, and the allocation for NAT444 is truly private within 
their network, why can't they simply agree "swaps" of their own existing 
allocations? ISP1  would agree to share a portion of their space to ISP2 
and remove it from routes to the public Internet, in return for ISP2 
agreeing to reciprocate.

In all cases I believe this is operationally difficult but workable, and 
no more onerous than coordinating introduction of a new /10.

Certainly if you consider what NAT444 is going to break relatively speaking.

Can you or anyone else tell me what is happening behind my NAT router? 
No. It is all based on the assumption that users will be happy with a 
one-way Internet (outbound sessions only please outside of your ISP). 
AFAIK there are no hard usage stats for people who use uPNPv2, static 
DMZ or port translations, DynDNS (2 million people), Teredo, port 25 
forwarders, or other port forwarding and other NAT traversal mechanisms 
that will anyway most likely break with the introduction of NAT444 
together with its shorter NAT association times.

I therefore also reject the base rationale for the need for allocating a 
/10 in the first place for NAT444, as IHMO there are viable (if painful) 
alternatives.

I also argue that NAT444 cements ISP boundaries in the Internet, thus 
encouraging the very fragmentation that we're trying to avoid. If you 
want to offer an (application) service that requires two way sessions to 
users shut off behind a NAT444 ISP, you are going to have buy a 
dedicated connection and provide a dedicated host connected to the ISP 
who is using NAT444. Otherwise you are shut out. Meanwhile that ISP who 
implemented NAT444 in the first place already has this hosting in place 
(in the portion of the network that is ISP private) and thus has an 
advantage over any new entrant. If an ISP wants to do this in their own 
network then fine, but I don't think it should be encouraged, and they 
should figure out how to do that using existing mechanisms. At least in 
solutions like A+P or NAT64 or NAT44/DS-Lite everyone stuck on IPv4 is 
treated the same way.

Hope this clarifies my statement. If not please fell free to ask further 
questions/discuss.

best regards,
RayH

Jimmy Hess wrote:
> On Fri, Apr 29, 2011 at 4:40 PM, David Farmer<farmer at umn.edu>  wrote:
>    
>> I am curious about this following comment, could you please expand on it.
>> On 4/29/11 12:48 CDT, Ray Hunter wrote:
>>      
>>> Meanwhile new entrants to the ISP market are effectively shut out, due
>>> to the "last /8" allocation policy for IPv4 addresses coming into effect
>>> in the ARIN region.
>>>        
>
> I would say this is more inaccurate than accurate...  new entrants after
> exhaustion have _fewer options_ for expansion.
>
> New entrants will be harmed by IP exhaustion, and ARIN hasn't passed
> special policies that will protect new entrants at the expense of
> larger providers.
>
> An example of "protecting new entrants"  would be an APNIC style treatment
> of the final /8.
>
> It doesn't necessarily mean they are shut out. New entrants can still seek
> addresses through 8.3 specified transfer; they can join the waiting list.
>
>
> New entrants can obtain IP addresses from their upstream provider.
> New ISPs in the recent past have almost always had to obtain IP addresses
> from their upstream provider first anyways.
>
> Too few customers/service areas to justify the minimum allocation unit, /20..
> no initial network, no multihoming....
> But policies allow IPs to be obtained from upstreams.
>
> For sufficient  $$, upstreams will provide IPs.
>
>
> --
> -JH
>    

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110430/d3614b2c/attachment.htm>