First proposal - all who need space get it (fwd)
Karl Denninger
karl at mcs.net
Fri May 29 00:25:44 UTC 1998
This was proposal number one for OPERATIONAL changes to ARIN's functional
allocation policies. Note that this gets us to an objective,
neutrally-verified criteria that allows, IMHO, all organizations with a
legitimate use for PI space to have it.
I am expanding the discussion list to NANOG and the ARIN Members mailing
lists. Please post comments PUBLICALLY, or if you feel you cannot do so
without "cloaking" yourself, through someone else (who you trust to strip
the attribution).
FIRST PROPOSAL:
1) The allocation policy of ARIN should be changed to reflect that any
organization which can demonstrate that it can constructively use
PI space should be able to receive it.
"Constructively demonstrate" is stated to mean:
a) The organization is multi-homed, possesses an ASN, and
two or more independant T1-or-above rate connections to
more than one backbone or other carrier (ie: to an exchange,
to a NSP, to other ISPs). Documentation in the form of a
signed connectivity agreement for a period of at least one
year, or connectivity provable via existing network tools
(ie: treno) is sufficient to satisfy this requirement.
b) The ASN is visible at industry-accepted peering points and
shows multiple paths available (ie: "nitrous.digex.net")
c) The organization is EITHER:
1) Engaged in the business of selling connectivity
to the general public, or can otherwise document
a REASONABLE expectation that at least 75% of the
/19 will be fully utilized at some point in the
future during the expected lifetime of the IPv4
space (defined as 10 years). The firm must be able
to prove this without resorting to a claim of
confidentiality; in other words, you must be able
to show that you're in the business of doing this
from your public, visible, documentable actions.
OR
2) The firm contains enough employees, staff members,
and EXTERNALLY ADDRESSABLE infrastructure equipment
within its boundaries to qualify for efficient use
of a /19 on its own (ie: more than 5,000 staff
members).
2) To receive MORE space, regardless of the size of the organization,
the requestor must document that more than <X>% of the existing
space allocated to it is either;
a) In use internally;
OR
b) Delegated to actively visible customers who actually use
said IP address space.
An IP address shall be deemed to be "constuctively used" if any of
the following apply to it at the /32 level:
a) It responds to a PING or other network packet addressed
to it when queried.
b) It is properly referenced in both forward and reverse DNS
files, and the hostname is traceable and billable to a
customer who has ongoing revenue associated with same. (ie:
an ISDN connectivity provider sells a class of service which
has a /29 associated with it; they generate hostnames for
all 8 addresses, and the customer is routed behind those
addresses).
c) It is a member of a operational DCHP or other dynamic pool,
and is properly referenced in both forward and reverse DNS
maps.
d) It is delegated to a dedicated circuit or other routed business
customer, and is part of a block of no more than 64 addresses
assigned to that customer.
Network broadcast addresses (defined as "all ones" host
components) are excluded from these requirements, as are
"all zeros", since some equipment demands that the "zeros"
address remain).
The value for "X%" shall be set by discussion within the AC and
ratified by vote.
All organizations must prove up use in all blocks delegated to or
through them in order to receive any further delegation of space.
I recommend that the value of "X" be set somewhere between 50 and
70%. This provides for some "slop", particularly in dedicated
circuit customer situations (which are going to have some slop).
However, it also prevents the practice of assigning a /24 to a
customer who has five computers in their office - a practice which
is extremely common!
3) A delegate producing documentation for classes of service (a - c)
above may not claim privilege for these classes of information,
as such is discernable from an external connection.
4) A delegate producing documentation for classes of service (d) may
claim privilege as to the identities of the organizations involved,
and may redact that information from their submissions, however,
the actual allocations themselves must be documented.
5) All submitted documentation and prove-up performed under these
policies are public information and subject to challenge by any
member of the Internet community.
--
--
Karl Denninger (karl at MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin
http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV
| NEW! Corporate ISDN Prices dropped by up to 50%!
Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS
Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost
More information about the NANOG
mailing list