[rpd] Some thoughts, and some actions required

[Scott Leibrand]

If you also close any loopholes that would allow the soft landing pool to
be drained quickly (per your reply to Owen), then yes, I think that would
be sufficient.  Again, I don't have a strong opinion on how that should be
done: I'm just pointing out that it would be good to ensure some sort of
soft landing free pool remains for several more years to ensure IPv4 space
is still available for new entrants until the burden of interconnecting the
legacy IPv4 Internet to the IPv6 Internet switches from IPv6-only to
IPv4-only networks.

-Scott

On Thu, Jan 28, 2016 at 6:22 PM, Douglas Onyango <ondouglas at gmail.com>
wrote:

> Hi Scott,
> In this case, I think adding v6 deployment as an eligibility
> requirement should suffice?
> Whether it's on the first allocation/assignment or on subsequent ones
> can be discussed.
>
> Regards,
>
> On 29 January 2016 at 04:11, Scott Leibrand <scottleibrand at gmail.com>
> wrote:
> > There are certain needs for IPv4 space that only require uniqueness, but
> not
> > routability.  For example, router IDs often need to be unique IPv4
> addresses
> > (even when only routing IPv6), but they don't need to be announced to
> > anyone.  To date, most requests under 4.10 have been for /24s, and ARIN
> > considers "we'd like to route this block on the Internet" to be valid
> > justification for needing a /24, so the policy allowing (but not
> requiring)
> > smaller allocations doesn't do any harm.  ARIN already has to do
> > non-classful rDNS delegation for blocks >/24, so I don't think the burden
> > there (if people actually choose to request smaller blocks) will be all
> that
> > significant.
> >
> > I am not necessarily suggesting reserving *more* space: if you'd prefer
> you
> > could tighten up the eligibility requirements on some of the
> > already-reserved space.  I am only suggesting that completely exhausting
> the
> > AfriNIC IPv4 free pool, with no space left to allocate to new entrants
> for
> > any reason, would put African companies at a disadvantage to new
> entrants in
> > other regions, who all have some sort of space reserved for that purpose.
> >
> > -Scott
> >
> > On Thu, Jan 28, 2016 at 5:58 PM, Douglas Onyango <ondouglas at gmail.com>
> > wrote:
> >>
> >> Hi Scott,
> >> On 28 January 2016 at 23:25, Scott Leibrand <scottleibrand at gmail.com>
> >> wrote:
> >>
> >>
> >> > I would also suggest that at the very least the AfriNIC community
> >> > consider
> >> > an addition to the soft-landing policy that sets aside an IPv4 block
> >> > dedicated to facilitating IPv6 deployment, by making IPv4 addresses
> >> > available for IPv6 translation technologies, dual stack DNS servers,
> >> > etc.
> >> > Something like https://www.arin.net/policy/nrpm.html#four10 could be
> >> > implemented either by carving out a pool out of AfriNIC's existing
> >> > inventory, or by dedicating space newly redistributed from IANA for
> the
> >> > purpose.  Alternately, a RIPE/APNIC style "one block per network" soft
> >> > landing policy would accomplish a similar objective: making sure that
> >> > future
> >> > new entrants can continue to receive enough IPv4 addresses to talk to
> >> > the
> >>
> >> While I like the idea of promoting v6 deployment as we near
> >> exhaustion, I find the idea of further reserving the more space not
> >> very appealing. You must recall that the Softlanding has already
> >> reserved a /12 for unforeseen circumstances.
> >>
> >> Further, I am curious as to what motivated ARIN's choice to allocate
> >> /28-/24 block from the reserve in your policy
> >> https://www.arin.net/policy/nrpm.html#four10
> >>
> >> I can only see this approach either breaking the Internet, as people
> >> drop your routes on account of size, or additional reverse delegation
> >> work being created for the RIR.
> >>
> >>
> >> Regards,
> >
> >
>
>
>
> --
> Douglas Onyango, PRINCE 2, ITILv3
> UG: +256 776 716 138
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20160128/1835bdfd/attachment.html>