[AfriNIC-rpd] Staff Analysis & Implementation Comments: Reclamation of Allocated but Un-routed IPv4 Addresses

[Mark Elkins]

Although I think I understand the motive behind this proposal, that is,
to remove IP addresses from those who are not using them so they can be
used by those that need them, I can only agree with everyone else who is
objecting to this proposal on the grounds that a route to a prefix that
is not in the Routing tables does not automatically imply that that
route (prefix/block of IP Addresses) is not in fact in legitimate use.

ie - this part of the proposal is a really bad idea.

The timings given may also not be enough. Deployment of new circuits can
often be delayed by more than 30 days - even 90 days.

Keeping track of whether address space has yet been commissioned or is
still in use by the entity that acquired it is not necessarily a bad
idea, and using various views of the routing table is one way in which
to see if the address space is "in use" (though it might not be in use
by the original entity!) is one way of ticking one of several possible
boxes. Tracking payments is another. RPKI might one day be another.
Might be a huge job though.

Being sensitive and responsive (ie reactive) to people querying about
the use or non-use of address space might be a good thing to do?


On Fri, 2011-05-27 at 09:52 +0400, Mukom Akong T wrote:
> Proposal Name: Reclamation of Allocated but Un-routed IPv4 Addresses
> Reference: AFPUB-2011-v4-002-draft-01
> Author: Jackson Muthili
> 
> [1.0] Introduction
> 
> This proposal mandates AfriNIC to reclaim any IPv4 address space that is
> not seen on the Internet routing tables.
> 
> [2.0] The Proposal
> 
> Excerpt of the proposal
> 
> ---------------------------------------------------------------------------------
> The following will apply to all IPv4 allocations issued before policy is
> implemented:
> 
> 3.1) IPv4 allocations distributed by AfriNIC to the ISP must be seen in
> the routing table within 90 days of getting the addresses.
> 
> 3.2) AfriNIC must issue three (3) seven (7)-day interval warnings to the
> ISP that is in violation of 3.1 after the 90th day of getting the IPv4
> allocation.
> 
> 3.3) AfriNIC must regain the IPv4 allocation from the ISP seven (7) days
> after the last warning. The IPv4 space can be given to another ISP by
> AfriNIC when appropriate.
> 
> The following will apply to all IPv4 issued after the policy is implemented:
> 
> 3.4) IPv4 distributed by AfriNIC to the ISP must be seen in the routing
> table within thirty (30) days of getting the addresses.
> 
> 3.5) AfriNIC must issue two seven (7)-day interval warnings to the
> member that is in violation of 3.4 after the 30th day of getting the
> IPv4 allocation.
> 
> 3.6) AfriNIC must regain the IPv4 from the ISP seven (7) days after the
> last warning. The IPv4 can be given to another ISP by AfriNIC when
> appropriate.
> ---------------------------------------------------------------------------------
> 
> 
> [3.0] Actions to be Taken
> 
> **Update to AfriNIC internal resource management systems for automatic
> tracking of allocated but unrouted space and subsequent communication to
> non-compliant resource holders.
> 
> **Update to INRM training material and other appropriate online
> documentation.
> 
> 
> [4.0]  Implementation
> 
> In order to properly integrate the internal resource management system
> with efficient tracking of prefix announcements, significant code
> changes will be required, as well as coordinating with some external
> entities to get different views/perspectives of the routing table. It
> could take, with current resources, up to 12 months to implement this
> proposal.
> 

-- 
  .  .     ___. .__      Posix Systems - Sth Africa
 /| /|       / /__       mje at posix.co.za  -  Mark J Elkins, Cisco CCIE
/ |/ |ARK \_/ /__ LKINS  Tel: +27 12 807 0590  Cell: +27 82 601 0496

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4490 bytes
Desc: not available
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20110528/c5c31896/attachment.bin>