Reclamation of 192.0.0.0/8 space

Please see the below re the above, as discussed at at the
LIR WG mtg on Monday.

Mike

--------------------------------------8<----------------------------

Message-Id: <199701020201.LAA08209 at moonsky.jp.apnic.net>
To: pagan at apnic.net
Subject: IRE->PAGAN Minutes
Date: Thu, 02 Jan 1997 11:01:19 +0900
From: "David R. Conrad" <davidc at apnic.net>
Sender: owner-pagan at apnic.net

Hi,

Sorry for the long silence.  Holidays get in the way... 

I have changed the name of the working group mailing list to
pagan at apnic.net (pagan-request for administrivia -- it is a majordomo
list).  The IRE addresses (ire, ire-request) will continue to work.  I've
left the archive names as ftp://ftp.apnic.net/mailing-lists/ire/ire.* (it's
actually a symbolic link to ftp://ftp.apnic.net/mailing-lists/pagan/ire.*)
but new archives will be pagan.archive.*.

I've included the rough draft of the IRE minutes.  Please send
comments/changes/additions/deletions to me.

With respect to the goals document, the original plan was to have
a rough draft available by Dec 31.  This was a bit optimistic.  Hope
to have something by Jan 15.

Regards,
- - -drc
- - --------
IRE minutes, Monday, Dec 10, 1996

Minutes taken by sheer at eni.net, modified by davidc at apnic.net

New working group name
- - ----------------------

A rough consensus was formed on Policies And Guidelines for Allocation
of Network numbers (PAGAN).  The minutes will reflect that the name
has been changed to PAGAN.

Charter Review
- - --------------

The query was placed as to weather this is a replacement for 1466,
and/or 2050.  The rough consensus was that this BOF was organized to
revise 2050 to apply better to the future.

The comment was made, repeatedly, that "If you are interested in DNS,
go away. We have nothing to do with DNS"

The correction was made to the Dec 31, 1997 date to change from '
draft' to 'final version'.

The suggestion was made that goals shopuld be done sooner.  The change
was made to finalize the goals by Apr 1, 1997.  The April date will be
after the IETF, by suggestion.

Registry Status Reports
- - -----------------------

RIPE-NCC reported that nothing much has changed, although they had 8
people assigning addresses to customers, and the Europian address
allocation guidelines document was finished (RIPE 140).

APNIC reported that they had 3 full time and one part time staff, and
had about 125 members. Current distribution of (self-determined)
member "size" is running around 20% large, 30% medium, and 50% small,
with yearly membership fees of $10k, $5k, and $2.5k,
respectively. Currently APNIC is allocating out of the 210 block and
have alocated most of the AS number they had, have about 7 left.  Due
to tax considerations, APNIC will likely be forced to relocate from
Tokyo, Japan to elsewhere in the Asia Pacific Rim region.

A question was asked weather AP-NIC was still losing money. The answer
was no, APNIC has $275k in the bank.

InterNIC reports that around 95% of IP allocations are for ISPs.
InterNIC is faced with a lot of multi-homed ISPs, ISPs who need
routable blocks because they are connected directly to a NAP, and
direct assignments to end users.  The future of the interNIC IP
registry is to become a non profit org, similar to APNIC and RIPE,
with membership and fees, a NSI as the funding backstop until it is
self sustaining. A discussion will be held on the mailing list
(listserv at internic.net, send a message body of "subscribe NAIPR").

A question was asked what the fee structure was going to be like. The
answer was that it would resemble APNIC's. Once the membership is
built up, it will be up to the members what the fees are.

A question was asked what happens to end user IP allocations. The
answer was that right now, there is nothing to discourage end users
from hitting the NIC up for addresses, in fact, under RFC1814, the
registries must provide address space.  There will be a discussion
over whether RFC 1814 will be moved to historic.

nA question was raised whether membership to the new IP registry will
be open or not.  The answer was yes.

A question was raised whether large end users can become members of
the registry. The answer was yes.

Time frame is for establishment is around April, 1997.

Rough consensus was formed for the InterNIC's new registry plan.

192 recovery
- - ------------

"Long ago and far away before much of this had happened, there was a
tremendous amount of dead space in the IPv4 allocation pool".  All of
the contacts listed in the /8 space were asked if they were done with
it, and if so, if they would bring it back. So far, 13% of the total
IPv4 space has been recovered.  There are now more addresses in the
free pool than there were 18 months ago.

The 192 space is considered to be one of the largest problems with
routing tables (the C class dumping ground). So attempts were made to
recover the 192 space. Most of the attempts resulted in email bounces. 
About 3000 responded, of which, 10% turned over their space. Most 192
space turned out to be allocated, but not connected and seeable from
the public internet.

One problem with recovering the space is finding out what registry is
authoritative.  The US DOD NIC was keeping information in the 192
space, as well as RIPE-NCC.

The information about this project was posted in NANOG.

About 1/3 of the 300 IP addresses recovered were in the global routing
table.

The point was made that the most important thing learned by the 192
reclimation project is that we don't know that much about that space.

A question was raised as to whether the effort should be formalized. A
rough consensas was yes.

The question was raised how NICs were keeping their databases up. The
answer from APNIC was that they were polling the database to find out
when the information was bad, although there had been no resolution
yet as to what to do when they found out it was.

JPNIC Class B Utilization Survey
- - --------------------------------

JPNIC IP Working group email address is ip-wg at nic.ad.jp

Purpose:
	- To study address utilization
	- Not to force to return addresses

Survey Form:
	- Emailed to 770 Technical and adminstrative contacts of 404
          class-B's in Japan in late August
	- 246 replies received by October 22

Some statistics were presenented
	- Average number of hosts is ~2k, std dev is 3180
	- Average number of connected hosts is 843, std dev is 3480
	- Average number of hosts per subnet is 15.23, std dev is 150

The rough consensus was that the standard deviations of these
statistics imply the statistics are not particularly useful.  Also
organizations should probably consider renumbering (among much
laughter)

The question was raised when the survey was sent out, how many emails
to the contacts bounced? The answer was somewhere on the order of 10%

"Goals" derived from Jim Browning's mail on the IRE mailing list
- - ----------------------------------------------------------------

* IPv4 Internet address space is a limited resource which requires
  conservation and management

Discussion:

Suggestion that this was not a goal and that IPv6 space is also
limited.

Is our goal to further limit it?  Suggested that the issue was not to
limit, or to conserve, but rather to manage the address space. There
has not been a lot of management of the IPv4 address space. The reason
management is neccesary is that the resource is limited.

Rewritten:

- - - Because IPv4 Internet address space is a limited resource, the goal
is to manage it.

Suggested that we are trying to maximize utility and longevity of ipv4
space and that this group should produce guidelines and protocals by
which the space can be managed.

* The current address allocation policy requires subjective
evaluations on the part of registry personnel.

A question was asked must allocations of address space have a
human-resource element?  Rough consensus was yes.

* There are aspects of the current address allocation that make things
difficult, particularly with ISPs that are just starting out or which
are growing quickly.

General agreement.

* Conservation of address space and slowing the growth in the size of
the rout table can be conflicting goals, and priority is given to
slowing the growth in the routing table

General agreement.

* Registries should assign routable address blocks to qualified
requesters. The maximum routable prefix should be dtermined by
collecting filtering policy information (as it relates to prefix size)
from all requesters:

Observation: The registries can not determine what is routable.  It
has been proposed that when orginizations submit request forms, they
list the prefixes that they route from. This would allow probibility
of routability to be calculated.  It was noted that this will, at
best, simply provide a snapshot of routability at one particular
instant in time.

* Mechanisms are needed to evaluate wheather allocated space is being
utilized effeciantly, and reclaim unused space.

Observation was made that it "would be nice" if allocations were
useful, however how can registries determine if allocation is
routable?  Routability information is short lived and only reflects
policy at time checked.  While it would undoubtedly be good to collect
information about routability, perhaps the allocation registries are
not the best organizations to collect it.

It was noted that address prefixes are not in absolute terms routable
or non-routable, end result -- registries cannot determine that address
space is useable.

After much discussion, the rough consensus was that registries will
assign address blocks to requestors.

Question: Who is going to try and reclaim address space?

Submitted that there is a need to provide tools to people to determine
wheather they are doing efficiant utilization.  Query as to whether
the creation of such tools should be a goal of the working group.

Comment that reclamation of address space might present a conflict of
interest if non-profit orgs are being created that are
leasing/selling/providing address space to downstream providers
without any type of higher control or feedback mechanism to guage
utilization.

* Mechanisms are needed to evaluate wheather allocated space is being
utilized effiecently (an acceptable percentage of allocated addresses
are actually assigned to hosts)

General agreement.

* Mechanisms are needed to reclaim unused address space.

General agreement.

* Recipients of provider independent space must maintain an
acceptable ratio of their number of announced prefixes to their
number of registry assigned prefixes in order to obtain additional
address space. 

Observation that such a statement need more words, particularly
regarding multihoming.

The ratio discussed on the IRE list was 1:1.

Suggestion was made that registries should not make unenforceable
limitations.  Question is does the registry have to look after
aggregation or not?  Goal of the statement on the list was to limit
the number of routable entries in the tables, not to limit address
hoarding.

Goals suggested as:

Conservation - Have address space available
Aggregation  - cleaan routing table
Registration - able to maintain contact

all within the context of fairness (since registries should be
fair accross all 3 goals).

Question raised as to what the cost of each of these items is?  Answer
proposed as sometimes they must be traded off against each other.
Fairness is suggested to be a seperate issue because it is subjective,
and unable to be reduced to objective form.

Question: do the registries have to be subserviant to the providers.
Comments from the registry personnel is that the organizations which
the registries allocate to are their customers.

Suggested that part of the goal of this working group is to provide a
document with goals for the registries.

Address Transferability
- - -----------------------

Presented by Yakov Rehkter.

It was proposed that orginizations perhaps should be allowed to
transfer addresses to other orginization and that this will provide
further aggrigation oppertunities in the address space.

To keep the discussion distinct from PIARA discussion, the approach
suggested for the discussion was swaps should be allowed if registries
permit it.

Problem pointed out that the buyers of address space are often not
ISPs, but large corporations.

Comment made that if we begin selling and buying address space, the
IRS will then start taxing ownership of an Internet address.

Suggested that what market equilibrium will do in this case is that
every group will get broken into the smallest address space that is
routable. This will result in the world's ugliest router table.

Filtering Information in Registration Database
- - ----------------------------------------------

Proposed that it would be usefull if someone could predict the
routability of an adress.

General consensus, but unclear whether allocation registries should
perform this function.  Clearly this is a routing registry function.

Address and Routing Registry Integration
- - ----------------------------------------

Pointed out that the two databases have very different needs, and very
different results, because one is required and the other is strictly
voluntary.  Suggestion on the mailing list was that the allocation
registry take into account routing registry database information
before making a decision.  Comment that perhaps the informational
service of having routing database registry integrated with address
registry might be worth having.  Comment that we would more likely get
results if a registration for address space also included a routing
registration.  Comment that it would be usefull, but it is not
possibile to force people to provide routing data.

"We have not had good experience with voluntary registration in any
database to date"

Allocation Policy Modifications to Allow New Isps to Obtain More Space
- - -----------------------------------------------------------------------

Suggested that a maintainence fee be charged for updating contigious
space, email attempts to contact owners of address space, and if it
isn't possible to contact owners of address space, records be deleted
from database.

Suggested that people be charged for incorrect or missing data,
wheather than correct data.  Pointed out that it would not be possible
to charge for people that have no proper contact data.  Response was
to delete the record.

Question as to what happens when the registries delete the entry from
the database. Pointed out that if address is in route space, it will
not stop being used, and will continue to function correctly.
Response that the registry will contact the ISP, which will then
contact the customer.

Pointed out that this is a chance to encourage people to form logical
aggregated CIDR blocks.

Question from an ISP: "If you take away their whois record, but can't
stop people from routing to them, why'd they pay up? -- If our
customer doesn't pay you, we should cut them off even if they pay us?"
Response: the question is is the registration database usable. If so,
the ISPs must pay a role in maintaining that database.  Point that the
benificiaries of the cleanup are the ISPs, which gives them more
access to the addresses in the pool, and also cleans up the routing
table.

Question as to what happens when someone tries to steal an address
block.  Response is that the ISPs should, and usually do check, and
other ISPs "tell on them"

Comment from ISP that has gotten customers that accidentally gave the
wrong class C.

RIDE 
- - ---- 

Proposed working group: Registry Information Database Exchange formats

(see slides , David Kessens)

Mailing list is ride at isi.edu (Majordomo)

Join if wish to join the fray for a commen registry database format
and exchange format

Closing
- - -------

IRE/PAGAN is hoped to soon be a working group, provided that there is
a working group chair. The working group chair will be David Conrad,
with a co-chair of Kim Hubbard

Question as to what to do first, proposed answer is goals document