Re: Get as much IP space as you ever dreamed of, was: Re: Looking to buy IPv4 addresses from class C swamp
Thus spake "Daniel Golding" <dgold@FDFNet.Net>
ARIN needs to repo any space that has [not] been advertised for a reasonable length of time, and reissue it.
So you're claiming that ARIN should revoke any allocations, including those made before it came into existence, simply because the addresses aren't in the global tables?
Life's not that simple. First of all, there is a long-standing agreement that one can legitimately receive IPv4 address allocations even if the addresses are not to be used on the public Internet. Therefore it is unreasonable to use the fact that an address block is not announced to justify revocation. IPv4 addresses are allocated to organization who need to use globally unique IPv4 addresses. On the other hand, if an RIR is unable to verify contact information for an allocated netblock, then they should remove the existing bad contact information and tag the block in some standard way in the whois directory that they publish. Those who wish to may use this standard tag to add a block to their filters and disallow its use on their network. Of course, this would be easier if the RIRs would all publish their whois directories using the IETF standard directory protocol (LDAP) because then anyone could query for all blocks with this standard tag without having to suck down a copy of all of the RIR databases and parse it themselves. I really don't think it is productive to look at this as a revocation issue. It's really an issue of the RIRs maintaining an accurate database of contact information and then providing full disclosure of that information. Currently, if the RIRs are unable to contact an netblock holder, nobody knows about it. We don't even know if they have tried because the antiquated whois directory systems in place today make it hard for them to add additional attributes and hard for us to query additional attributes. The fact is that when an RIR allocates address space, there is a transfer of responsibility over the use of that address space. The public has a right to know who is taking responsibility for use of every block of IPv4 addresses. ISPs can then make their own routing and filtering decisions using that data if they choose to. This doesn't mean that the RIRs or ISPs should publish contact information about every DSL customer using a /30. In fact, the RIRs and ISPs should be publishing less information in their public whois directories, not more. The key factor here is responsibility. Sometimes when a block of IP space is allocated or assigned, the recipient is willing and *ABLE* to take public responsibility for the use and abuse of that space. In that case, their contact info should go in the public whois directory. But when the responsibility is not delegated to the recipient then there should be nothing in the public whois directory. If we had a clean and complete directory mapping the organizations repsonsible for every part of the IPv4 address space then things like revocation would simply be a non-issue because ISPs would have the information that they need to make their own independent decisions about routing and filtering. The RIRs should never be an enforcement agency however they should pay more attention to being an authoritative source of accurate and complete data. The whole RIR system today is mired in the past. They need to pull their socks up, cooperate more, clean their databases up, put the right information in their databases, and use the standard protocols that the IETF has already designed for directory service rather than wasting time on reinventing the wheel again. --Michael Dillon
using the IETF standard directory protocol (LDAP) because then anyone could query for all blocks with this standard tag without having to suck down a copy of all of the RIR databases and parse it themselves.
Is there a place where all the databases could be sucked down easily or are they still dispersed around and the formats differ for different continents? Pete
participants (2)
-
Michael.Dillon@radianz.com
-
Petri Helenius