[rpd] LACNIC reaches final /10 of IPv4 space

Wed Jun 11 07:51:24 UTC 2014

(Responding in my personal capacity once again)

> 1 - What about "except for the very first allocation/assignment, No more IPv4 until the member has their own IPv6 from AFRINIC, visible in the routing table" ???
> Would love to add that if the members upstream(s) do not support IPv6 connectivity to the member, no more IPv4 for them either.

I'd have no issues with this requirement, though a slight concern that this may lead to massive tunneling that will never be reverted to native v6.

> 2 - What about "for the second last /8, anyone acquiring addresses from this pool has to prove (onus on the member) that more than half of their existing addresses are used on \
> equipment within the AFRINIC service region" ???

I'd have serious issues with this last one.  Purely because I'm not sure how you would prove it, short of disclosing exact equipment and locations to AfriNIC, and I think that may set a dangerous precedent.  I also am far from convinced that we should be all that concerned about where the space is used.  The arguments about geographic location of IP space are complicated, particularly on a continent that is still so heavily reliant on satellite communications unless you're at a costal region, and how do you prove where the other end of a satellite connection is?  Let's face reality, IPv4 is in its death throws, lets stop trying to figure out which hospital to put it in, and how to extend its life support, and let it pass peacefully and move on.

> 3 - I also think a reservation policy might be useful for large requests.
> Client wants a /12, AFRINIC can reserve the whole /12 but only issues a /16 of it - for use in "chicken and egg" cases... where funding might not be (fully) approved until
> resources are secured. The rest of the /12 is issued later (on qualification) as part of the same job.
> (I use /12 and /16 purely as examples)

I have no issues with this, provided that the applicant doesn't pay huge financial penalties for this.  It would need to be very closely analyzed to see how this would work in terms of the current billing structures and where the limits of policy are in setting this.  For example, if a client applies for a /12, and is allocated the /12 in blocks as he moves forward, should he have to pay a separate application fee each time he gets more space out of that block?  That is my only concern with this.

Just my thoughts.

Andrew

On Wed, 2014-06-11 at 09:43 +0400, Kris Seeburn wrote:
> There are two ends to it.
>
>
>       * We either look at a policy to protect our ipv4 space which
>         would actually defeat the full push of ipv6
>       * Or we find ways to deplete our ipv4 space faster that we can
>         move to ipv6 faster
>
>
> We all know that most hosting / ecom sites are still based on ipv4
> infrastructure though. As much as we need to protect the ipv4 space we
> still need to push the ipv6 space. Afrinic nevertheless still has a
> good deal of ipv4 space. The question is how do we move both agenda
> forward?
>
>
> I think obviously we need to look at our policy and what can make
> things work for us. A sharing or sales of ipv4 space with other RIRs
> as need may also look as a better way of still protecting the precious
> space whilst still making money out of it. I am not sure. I think this
> is still a dilemma we all need to figure out.
>
>
> NB: This is not a board perspective but my personal take at it.
>
>
> Kris
>
> On Jun 11, 2014, at 9:17 AM, Bope Domilongo Christian
> <christianbope at gmail.com> wrote:
>
> > Thank you Alan and seun, this an important  milestone, having a
> > policy to protect our critical resources will be great.
> >
> >
> > With best regards,
> >
> > writing on my personal capacity.
> >
> >
> >
> > On Wed, Jun 11, 2014 at 4:13 AM, Seun Ojedeji
> > <seun.ojedeji at gmail.com> wrote:
> >         Thanks for this update Alan, from all indication it will
> >         seem that v4 exhaustion time within AfriNIC region may be
> >         sooner than earlier predicted.
> >
> >         Should this region be worried?... maybe:
> >         - More content in those region where v4 is getting exhausted
> >         will go v6 but then v6 deployment in our region is
> >         relatively low (someone says there is translation to the
> >         rescue)
> >         - Our region will continue to experience an increase in v4
> >         requests from organizations that are more domicile in
> >         regions with v4 exhaustion. Perhaps this could be an
> >         opportunity to "by policy" improve ISP establishment in our
> >         region? Maybe yes. Should we also "by policy" ensure
> >         addresses within this region are used more within the
> >         region.... how do we encourage this as the region seem to be
> >         comfortable with *translation*. Can policy make this happen?
> >
> >         Cheers!
> >         PS: My views alone.
> >         sent from Google nexus 4
> >         kindly excuse brevity and typos.
> >
> >         On 10 Jun 2014 17:23, "Alan Barrett" <apb at cequrux.com>
> >         wrote:
> >                 Three weeks ago, on 20 May 2014, LACNIC's available
> >                 pool of IPv4 space became less then a /9
> >                 equivalent.  This triggered the activation of IANA's
> >                 Recovered IPv4 Pool in terms of Global Policy
> >                 GPP-IPv4-2011.
> >
> >                 Today, 10 June 2014, LACNIC's available pool of IPv4
> >                 space became less than a /10 equivalent (4194302
> >                 IPv4 addresses).  This triggers LACNIC's IPv4
> >                 exhaustion policy.
> >
> >                 Announcements from 20 May 2014:
> >                 <http://www.nro.net/news/lacnics-ipv4-address-pool-now-down-to-a-9>
> >
> > <http://www.nro.net/news/iana-allocates-recovered-ipv4-addresses-to-
> > rir>
> >
> >                 Announcement from 10 Jun 2014:
> >
> > <http://www.lacnic.net/en/web/anuncios/2014-no-hay-mas-direcciones-i
> > pv4-en-lac>
> >
> >                 --apb (Alan Barrett)
> >                 _______________________________________________
> >                 rpd mailing list
> >                 rpd at afrinic.net
> >                 https://lists.afrinic.net/mailman/listinfo.cgi/rpd
> >
> >         _______________________________________________
> >         rpd mailing list
> >         rpd at afrinic.net
> >         https://lists.afrinic.net/mailman/listinfo.cgi/rpd
> >
> >
> >
> > _______________________________________________
> > rpd mailing list
> > rpd at afrinic.net
> > https://lists.afrinic.net/mailman/listinfo.cgi/rpd
>
> Kris Seeburn
> seeburn.k at gmail.com
>       *
>                 www.linkedin.com/in/kseeburn/
>
>
>
>
>
>
>
> _______________________________________________
> rpd mailing list
> rpd at afrinic.net
> https://lists.afrinic.net/mailman/listinfo.cgi/rpd

--
Mark James ELKINS  -  Posix Systems - (South) Africa
mje at posix.co.za       Tel: +27.128070590  Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za

DISCLAIMER:  This email contains proprietary information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this email, please notify the author by replying to this email. If you are not the intended recipient, you must not use, disclose, copy, print, or rely on this email.  We cannot accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of this company or one of its agents.