[rpd] New Proposal - "Soft Landing - BIS (AFPUB-2016-V4-001-DRAFT-01)"

[Nishal Goburdhan]

On 9 Feb 2016, at 15:46, Seun Ojedeji wrote:

> Dear Members,
>
> We have received a new policy Proposal - "Soft Landing - BIS
> (AFPUB-2016-V4-001-DRAFT-01)"
> *2) Summary of How this Proposal Addresses the Problem*
>
> This policy proposal solves the problem described above by:
>  Changing the value of the maximum allocation/assignment size during 
> the
> exhaustion phase 1.
>  Imposing IPv6 resources as a pre-condition to IPv4 resource requests
> during the exhaustion.
>  Reserving address spaces for Critical Internet Infrastructure and new
> LIRs or End-Users.
>  Removing the minimum allocation size as this may evolve over time
> during the exhaustion period.

personally, i think your problem statement is off.  soft-landing was 
never about imposing IPv6 (perhaps the author can correct me).  it was 
about how to deal with IPv4 runout, gracefully.

i do *not* support the part about enforcing IPv6.  regardless of what 
you or i might think, there are some organisations that do *not* want to 
do this.  disallowing them access to a once-off, small pool of IPv4 
addresses because of their business reasons, that do not see them using 
IPv6, is incorrect.  if the AIRRS report is anything to believe, simply 
allocating IPv6 resources is not actually helping IPv6 *deployment* in 
any way, in this region.  i don’t believe that an enforced allocation 
is actually going to change that;  but i also do not want, say the 
factory with legacy embedded devices, that do not warrant upgrades, but 
require uniqueness, to be disadvantaged by this.





> *3) Proposal*
> 3.1 The policy proposal changes clause/article 3.5.1 of the current 
> IPv4
> Soft Landing Policy to:
> 3.5.1 EXHAUSTION PHASE 1During this phase,allocation/assignment of 
> address
> space will continue as in the Current phase with no explicit minimum 
> but
> the maximum will change from /10 to /15.

should this be /13 to /15?


> Allocations and assignments will be made from the Final /8 or from any
> other IPv4 address space available to AFRINIC, until no more than a 
> /11 of
> non-reserved space is available in the Final /8.
> At this point, exhaustion phase 2 will begin.
>
> For the avoidance of doubt all applications that will be in process at 
> this
> point will be evaluated as per the new policy.
>
> 3.2 This policy proposal changes Clauses/Articles 3.6, 3.8 and 3.9 of 
> the
> current IPv4 Soft Landing Policy to:
> 3.6 If any LIR or End User requests IPv4 address space during 
> Exhaustion:
> There is no explicit limit on the number of times an organization may
> request additional IPv4 address space during Exhaustion Phase 1. 
> During
> exhaustion Phase 2, new LIRs or End-Users can receive only one
> allocation/assignment from the new LIRs or End-Users reserved pool.

so a new LIR can get resources once, then become an existing LIR, and 
get resources again, since “there is no explicit limit … “    that 
doesn’t seem right to me, but perhaps i’m reading it incorrectly.


> 3.8 Allocation CriteriaIn order to receive IPv4 allocations or 
> assignments
> during the Exhaustion Phase, the LIR or
> End User must meet IPv4 allocation or assignment policy requirements 
> and
> must have used at
> least 90% of all previous allocations or assignments (including those 
> made
> during both the Current Phase and the Exhaustion Phase).
>
> In the case of new LIRs or End Users with no previous allocations or
> assignments, this requirement does not apply to their first allocation 
> or assignment request.
>
> LIRs and End users requesting IPv4 space must have IPv6 resources from
> AFRINIC (or request IPv6 concurrently with their IPv4 request), or 
> from
> their upstream providers.

do not support (see above).

> AFRINIC resources are for the AFRINIC service region and any use 
> outside
> the region should be solely in support of connectivity back to the 
> AFRINIC
> region

do not support.  this precludes a legitimate business, obtaining 
resources for use in something like anycast, because, by definition an 
anycast node will not connect back to the continent, while at the same 
time being live on the continent.  and no, this isn’t covered in the 
anycast policy, which specifically limits allocations to a /24.

if you want to know what i’m talking about, read jerome’s messages 
about how cloudflare operates their anycast network here:  
https://lists.afrinic.net/pipermail/rpd/2015/004569.html   networks that 
need more than a /24 are forced to use the EU policy, and this proposal 
overwrites that legitimate business use case.  perhaps consider putting 
in exceptions in a policy addendum;  something like “while the service 
is concurrently available within the AfriNIC service region”, or 
similar, would help the hostmasters understand what you mean, while not 
disadvantaging legitimate use.



> 3.9 IPv4 Address Space for [Internet Exchange Points (IXPs)], critical
> Internet infrastructure, new LIRs or End-Users and unforeseen 
> circumstances
> During exhaustion phase 2, allocations/assignments to IXPs, Critical
> Internet infrastructure and new LIRs and End-Users will be as follows:
>
> 3.9.1 Assignments to critical infrastructure
> A /16 from the final /11 will be held in reserve for exclusive use by
> critical Internet infrastructure. On application for IPv4 resources, a
> critical Internet Infrastructure operator may receive one number 
> resource
> (maximum /22).
>
> Critical infrastructure are ICANN-sanctioned DNS root server 
> operators,
> IXPs, TLD (Top Level Domain) operators, IANA and RIRs.


this policy proposes a definition change as to what constitutes critical 
internet infrastructure.  how does this fit in with existing 
definitions;  is it the authors’ intent that CIR is redefined only at 
phase X in runout, or at policy ratification, or […].   i could make a 
guess, but i’d prefer to hear what the original intent is, please.

additionally, is .mysexynewtld (ie. ngTLDs) considered critical?   or 
did you mean ccTLDs?

while we very, very patiently(!) wait for staff implementation of 
AFPUB-2014-GEN-004, is it your intent that IXPs should share the same 
“reserved” pools with others?   i’ll remind those of you that 
don’t run IXPs that, a specific request from AFPUB-2014-GEN-004 was to 
have a reserved block that would ensure uniqueness, whilst not being 
visible in any view of the global routing table.

having a combined pool sort of defeats that point - pretty much in the 
manner how the once reserved 196.223.x pool (which was meant to be for 
IXPs only) now has other other “cybersquatters” in it …


>  On application for IPv4 resources, an Internet Exchange Point (IXP)
> will receive one number resource (maximum /23) according to the 
> following:
>  This space will be used to run an Internet Exchange Point peering 
> LAN;
> other uses are forbidden.
>  New Internet Exchange points will be assigned a maximum of /24.
> Internet exchange points may return this assignment (or existing PI 
> used as
> in the IXP peering LAN) should they run out of space and receive a 
> larger
> (a maximum of /23 if utilization requires) assignment.
>  IP space returned by Internet Exchange Points will be added to the
> reserved pool maintained for use by Internet Exchange Points.

while it’s certainly not common, if this is exclusively for IXP 
peering networks (at least that’s what i think the intent of this is), 
why do you limit this to /23?  i’m sure the afrinic hostmaster team 
are capable of assessing a legit IXP’s needs.


> 3.9.2 Allocations/Assignments to new LIRs or End-Users
>
> A /14 from the final /11 will be held in reserve for exclusive use by 
> new
> LIRs or End-Users with no prior IPv4 address space from AFRINIC.  On
> application for IPv4 resources, a new LIR or End-User may receive one
> number resource (maximum /22).
>
>
> 3.9.3 Reserve for unforeseen situations
>
> A /13 IPv4 address block will be in reserved out of the Final /8. This 
> /13
> IPv4 address block shall be preserved by AFRINIC for some future uses, 
> as
> yet unforeseen. The Internet is innovative and we cannot predict with
> certainty what might happen. Therefore, it is prudent to keep this 
> block in
> reserve, just in case some future requirement creates a demand for 
> IPv4
> addresses.

keep in perpetuity?
or..?

as it stands, this doesn’t make sense, but i’d like to see more of 
the thinking behind this.


> When AFRINIC, can no longer meet any more requests for address space 
> (from
> the Final /8 or from any other available address space), AFRINIC in
> consultation with the community via the Policy Discussion Mailing list 
> and
> considering the demand and other factors at the time will replenish 
> the
> exhaustion pool with whatever address space (or part thereof) that may 
> be
> available to AFRINIC at the time, in a manner that is in the best 
> interests
> of the community.

…and, while a policy for that is passed, do requests stay unmet in the 
pool?   i’m sure that’s not your intent.

—n.