Using unallocated address space

Hank Nussbacher hank at att.net.il
Thu Feb 15 19:13:52 UTC 2001


At 10:58 15/02/01 -0800, Alan Hannan wrote:

> > The registries, ARIN/RIPE/APNIC should announce the offending block
> > themselves and shunt it to null0.  If the offender announces a /18 then
> > they should announce theirs as 2x/19s and thereby override the bogus /18.
>
>   While a novel idea, I believe it is particularly dangerous to
>   have an allocation registry strictly control operational use.
>
>   A separation of power between the allocation and the dynamic-real-time
>   use of address space is beneficial for many reasons.
>
>   Historically, this separation of power has been maintained.  For
>   example, Sprint/smd's draconian filtering and aggregation policies
>   were synergistic with address allocation policies, however, allocation
>   rules were based upon different enforcement methods.
>
>   Allocation registries allocate 'temporary ownership' of address
>   space, without any respect for routability of address space.
>
>   Allow the ISPs to police themselves, perhaps with assistance from
>   ARIN/RIPE/APNIC.  If they choose not to police themselves, that
>   is their prerogative.
>
>   I would support an available list of routes or BGP feed of allocated
>   v. unallocated space, which ISPs could subscribe to so as to
>   self-police proper address usage.  In fact, it's unclear to me how
>   ARIN could affect the routing of others, without dictating that ISPs
>   respect their announcements.  And I certainly would not want that.

Self policing has been tried for years.  It don't work.  "Seperation of 
power" is a nice utopian ideal, but when you have IP cybersquatters out 
there who know how to abuse the system, they will win.

I know of a case where a LIR assigned a block to an organization and 
revoked it a year later after the organization did not meet the standard 
requirements.  The organization is signed on an agreement to follow the 
standards.  The LIR revoked the IP block, but the upstream ISP continues to 
announce it since it is signed on an agreement with the organization to 
provide routing and doesn't want to risk a lawsuit from the 
organization.   So this block is now dead in the water since it can't be 
reassigned to any other client since it is in pseudo-use.

No ISP will risk a lawsuit by black-holing something.  This has to be done 
by the allocation agency (ICANN or ARIN/RIPE/APNIC).

-Hank


>   All in all, this proposal is flawed for many reasons.
>
>   The goal of keeping the internet from splintering and properly
>   using allocated space is a good one.
>
>   This proposal is not the right way to help achieve that goal.
>
>   -alan
>
>
>
>Thus spake Hank Nussbacher (hank at att.net.il)
>  on or about Thu, Feb 15, 2001 at 07:31:52PM +0200:
> >
> > At 22:56 12/02/01 -0800, Sean Donelan wrote:
> >
> > >On Mon, 12 February 2001, John Fraizer wrote:
> > > > Any time a network is caught announcing non-allocated address 
> space, the
> > > > registry should bill them accordingly.  If they refuse to pay, the
> > > > registry should yank their ASN.  That would be strong encouragement 
> to do
> > > > the right thing.
> > >
> > >Other than making it difficult for people to figure out WHOIS using that
> > >ASN, "yanking" an ASN's registration has little practical effect.  You
> > >can use an un-allocated ASN almost as easily as using an un-allocated
> > >address block.
> >
> > The registries, ARIN/RIPE/APNIC should announce the offending block
> > themselves and shunt it to null0.  If the offender announces a /18 then
> > they should announce theirs as 2x/19s and thereby override the bogus /18.
> >
> > I don't think the problem is so huge that a few dozen extra prefixes
> > announced by the registries will bloat and kill the routing table 
> size.  If
> > the registries don't do this, these cybersquatters will come thru later on
> > and demand to keep the IP address space they have grabbed just as the 
> .sex,
> > and .web and all the other alternate DNSers have done.
> >
> > -Hank
> >
> >





More information about the NANOG mailing list