<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Sorry my wording was maybe rather unfortunate. Let me try to rephrase.<br>
[Blush. This time with APNIC and ARIN in the right places]<br>
<br>
I actually explicitly support the APNIC 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
large new
entrants in AP will have a difficult but perhaps to impossible time, as
they can only obtain a single /22 allocation. Ever.<br>
<br>
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)<br>
<br>
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 APNIC). I know who these allocations were made to
(via
whois), but have kept the data anonymous.<br>
<br>
number of addresses in allocation - number of organizations obtaining
precisely one new ASN and one new IP block in calendar year 2011 to date<br>
<span class="comment-body"
data-li-comment-text="@John. I'll give it a go, but my first parse of the whois information would suggest classifying/tagging the data may not be trivial. Great hint about the AS allocation BTW.There were 166 new AS allocations in 2011 in APNICs data.I have managed to link 105 new ASN's allocated this year to single network allocations. [this was not a trivial task I assure you, and took quite a bit of PERL to link things up, so there might well still be errors in my code if you intend to quote these stats anywhere]The names behind these allocations are generally pretty major companies or organizations that you might have heard of, including start up network providers and educational insitutions.And yet the allocations themselves are in the following ranges:* 25634* 5127* 102435* 204812* 40964* 81926* 163842* 327682* 655363total105The current available allocation is a /22 or 1024 address.Bear in mind these are just the subset of organizations that have already gone to the tr
ouble 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.This suggests to me that the problem is already serious.">*
256
- 34<br>
* 512 - 7<br>
* 1024 - 35<br>
* 2048 - 12<br>
* 4096 - 4<br>
* 8192 - 6<br>
* 16384 - 2<br>
* 32768 - 2<br>
* 65536 - 3<br>
<br>
total105 allocations<br>
<br>
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.<br>
<br>
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)<br>
<br>
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.<br>
<br>
That to me means these 29 organizations in APNIC would today
effectively be shut
out, because they couldn't even get their minimum requirement for
today. Smaller allocations are possible, but may or 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 realize
that they are rapidly approaching the same situation, and should think
carefully about what they consider a "fair policy" for the few
remaining addresses.<br>
</span><br>
<br>
<br>
<br>
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 for the last few addresses.<br>
<br>
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)?<br>
<br>
No, they won't, because they will no longer be globally unique.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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).<br>
<br>
So what I'm arguing is that ARIN allocating a /10 for NAT444 might make
things worse for new entrants.<br>
<br>
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.<br>
<br>
<br>
<br>
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.<br>
<br>
RFC1918 allocated huge address space for private use. The 10.0.0.0/8
network alone is far bigger than the requested allocation. <br>
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.<br>
<br>
The argument made for the need for the new /10 allocation was that
network 10/8 is in use on some end user gateways.<br>
<br>
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]<br>
<br>
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.<br>
<br>
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)<br>
<br>
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.<br>
<br>
In all cases I believe this is operationally difficult but workable,
and no more onerous than coordinating introduction of a new /10.<br>
<br>
Certainly if you consider what NAT444 is going to break relatively
speaking.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Hope this clarifies my statement. If not please fell free to ask
further questions/discuss.<br>
<br>
best regards,<br>
RayH<br>
<br>
Jimmy Hess wrote:
<blockquote
cite="mid:BANLkTinph6MjFZDnwN0WLUx=k4ZM-Tpxvw@mail.gmail.com"
type="cite">
<pre wrap="">On Fri, Apr 29, 2011 at 4:40 PM, David Farmer <a class="moz-txt-link-rfc2396E" href="mailto:farmer@umn.edu"><farmer@umn.edu></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I am curious about this following comment, could you please expand on it.
On 4/29/11 12:48 CDT, Ray Hunter wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
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
</pre>
</blockquote>
<br>
</body>
</html>