[AfriNIC-rpd] Re: Proposal: Reclamation of allocated but unrouted IPv4 addresses.

[Mark Elkins]

On Wed, 2011-02-09 at 20:04 +0200, Andrew Alston wrote:
> Hi Jackson
> 
> 
> 
> On 2011/02/09 7:41 PM, "Jackson Muthili" <jacksonmuthi at gmail.com> wrote:
> 
> > Andrew,
> > 
> > On Wed, Feb 9, 2011 at 7:21 PM, Andrew Alston <aa at tenet.ac.za> wrote:
> >> 
> >> I have concerns about this policy, since as has been stated in various other
> >> discussion forums, there are several reasons to have so called "live"
> >> (non-rfc1918) space that is not announced in the routing tables but is
> >> actively in use.
> > 
> > Correct. IXPs are one exception. I am willing to accommodate other
> > similar cases in the proposal.
> > 
> I can think of a LOT of exceptions.  Take for example the following (and I
> admit this is a very specific example, but it highlights the issue)
> 
> An ISP is running an IRC server, the server has two interfaces, one globally
> routable for uplinking to the IRC network in question.  One that is ONLY
> announced to national transits that is the "client" interface and that is
> actually visible.  This is done to avoid any form of denial of service
> attack against a commonly attacked service.  The IP space assigned to that
> "client" segment is DELIBERATELY not announced globally and never will be.

I actually do this with some address space for a particular IRC Network.
Before I did this - my ISP was badly hit by a DDOS.

> To accommodate this type of behavior on a case by case basis is going to be
> very difficult, and to attempt to do this narrowly to specific applications
> would amount to dictating what an ISP can do with their space with regards
> to their routing.  The  policy would need to be modified to state that
> limited announcement within a geographic area is permissible irrespective of
> the reason for it, as it is not up to the RIR to dictate those cases where
> it is or is not allowed to their client base.
> 
> >> Also, at which point are you evaluating the routing tables?  I can point to
> >> several instances where space is "partially" announced (within a geographic
> >> area, yet not propagated globally).  The space is completely valid and being
> >> utilized, but factors preclude its global announcement.
> > 
> > That is why time from issue to announcement has been defined.
> > 
> The timing is not at issue there, there are many cases where this is a
> permanent situation.
> 
> >> This proposal also makes no provision for the handling of so called legacy
> >> address segments, which would have to be dealt with as a separate issue.
> > 
> > It handles legacy IPv4.
> > 2.1 - 2.4 clauses cover for these scenario.
> > Those are in fact the key targets for the proposal.
> 
> I have a major problem with this.  Legacy allocations were issued before the
> RIR's were ever created, and were not bound by the policies that govern the
> current RIR's.  As such, while the RIR's do control such services as the
> whois, I believe it would be extremely problematic to attempt to force
> impose policies on the holders such space.  This has been the subject of
> much discussion recently on the nanog lists as well.
> 
> > 
> > Cheers
> > Jack

Jack - is this policy being sent to all RIR's or just AfriNIC.

Where are you geographically based?

Are you proposing this policy on behalf of someone else or a particular
entity or is this your own idea?


> _______________________________________________
> rpd mailing list
> rpd at afrinic.net
> https://lists.afrinic.net/mailman/listinfo.cgi/rpd

-- 
  .  .     ___. .__      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/20110210/b2b04506/attachment.bin>