[ppml] real data on PI assignments to end sites?
jeroen at unfix.org
Thu Mar 23 12:42:27 EST 2006
On Thu, 2006-03-23 at 11:18 -0600, Thomas Narten wrote:
> Geoff (or anyone else who can help),
> In trying to better understand the impacts of various PI-for-end-sites
> proposals, it would be helpful to me to understand how many PI
> assignments have been made to end sites in IPv4 today. That is, using
> IPv4 as a guide, is there data to help us understand the implications
> of setting the bar for how "large" an end site should be in order to
> be eligible for a PI assignment? Is it only in the thousands? Tens of
Taking that every business would want to not have the burden of
renumbering, every business would in effect want to have PI in the long
run. With IPv4 they can resort to NAT to avoid renumbering in some cases
where there is no inbound traffic, or simply do 1:1 NAT so that even
servers can be in the old address space (ignoring updating
firewalls/dns/etc at remote places and a lot of other issues).
These sites will thus not be really visible as having "PI" but they do
have a form of it and actually would really love to have it.
Counting them thus becomes quite impossible, but one could estimate that
a large portion of the global businesses would want to have it.
> Also, are there any trend lines that can help us understand where
> things are heading today?
> Is such data available, or are there ways to estimate this?
The big trouble is, as you most likely know, that many sites are behind
NAT's, which would actually very much like to have a globally unique PI
address space but could not get it for various reasons. Thus even if one
would take RIR data, there is most likely a large number of sites that
is not registered at all in the various RIR registries because they are
hiding behind a NAT.
Next to that various places don't want to be registered in a RIR
database to avoid competition being able to estimate their address space
size and thus being able to guess how much they have connected and other
privacy and obscurity reasons.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 315 bytes
Desc: This is a digitally signed message part
More information about the ARIN-PPML