[rpd] IPv4 Soft Landing BIS

[ALAIN AINA]

Hello,

I found the recent discussions on SL-bis interesting. I noticed we went back to some already discussed points, plus others.

Trying to undertand and sense the way forward, i came up the following discussions points:

1- Starving those who need the numbers now to protect some unknown future 

Those who needed numbers were informed to apply from the normal pool which ended when afrinic announced that the normal pool is exhausted
and Exhaustion phase 1 started. 

https://www.afrinic.net/en/library/news/2053-afrinic-enters-ipv4-exhaustion-phase-1 started with

"On 31st March 2017,AFRINIC has approved a request for IPv4 resources that could not be fulfilled from the IPv4 address space available in the AFRINIC pool (with the exception of the final /8), triggering Phase 1 of IPv4 Exhaustion."

At this time AFRINIC pool consists of the following :

- Normal pool which is replenished by returned/recovered space or IANA distribution of returned space 

- the Final /8,the 102/8

https://www.afrinic.net/en/services/statistics/ipv4-exhaustion

=====
FINAL /8

The following definition of the "Final /8" appears in section 5.4.1 of the CPM:

The Final /8 block of IPv4 address space, or "Final /8", is the /8 block of IPv4 address space that has been allocated 
by the IANA to AFRINIC in terms of section 2.2 C of the Global Policy for the Allocation of the Remaining IPv4 Address Space 
at the time of exhaustion of the IANA pool of IPv4 address space.
==============

The global policy adopted in 2009 explains why and how the final  /8 was obtained  - https://www.afrinic.net/en/library/policies/current/135-afpub-2009-v4-001

The current softlanding was adopted in 2011 to fulfil the mission and objectives assigned to the last /8 through a gradual  exhaustion:

-  phase 1 &  phase 2

- need based

- No limit on the numbers of time a member can apply as to "eliminate the possibility of remaining with unusable space in the pool". 
(https://www.afrinic.net/en/library/policies/current/697-ipv4-soft-landing-policy)

- reserve for unforeseen future.

##IPv4 pools##

Shall we separate the normal pool from the last /8 pool and allow distribution from the normal pool according the pre-exhaustion rules and the 102/8 pool with the softlanding rules ? 

"non-102/8 pool" and  "102/8 pool"


2-  Which SL-bis ?

SL-bis to version 4.0  

- stayed in the same spirit of the current SL(no limit on the number of requests from members during phase 1 and phase 2)

- reduce the max allocation in Phase 1 

- no change in phase 2

- Turn the unforeseen future reserve to IPv6 deployment reserve. 

SL-bis version 5.0 is a community version of the SL-bis(4.0), which introduced the limit of maximum allocation size to members during each phase from SL-SD.

Are we hearing, these limits are not wanted ?



3-  Promoting IPv6 deployment with the  last /8


a)  SL-bis had the following text in the allocation criteria:

"LIR and End users requesting IPv4 must have IPv6 resources from AFRINIC (or request concomitantly with the IPv4) or from their upstreams."

This was discussed. Even an amended version  with "deployment" instead of  "allocation" did not get consensus.

Are we hearing we shall bring it back? if yes in which format ?


b) SL-bis 4.0  has the following for an IPv6 reserve:

===
5.4.7 IPv6 deployment reserve
A contiguous /12 IPv4 address block will be reserved out of the Final /8 to facilitate IPv6 deployment.

When AFRINIC, can no longer meet any more requests for address space (from the Final /8 or from any other available address space),
allocations and assignments from this block must be justified by needs for IPv4 addresses space to support IPv6 deployment. 

Examples of such needs include: [IPv4 addresses for Core DNS service providers’ dual stack DNS servers,464XLAT translators or any other translators
as defined by the IETF. This block will be subject to a maximum size allocation of /24


5.4.7.1 AFRINIC staff will use their discretion when evaluating justifications and should use sparse allocation when possible within that /12 block.

5.4.7.2 In order to receive an allocation or assignment from the IPv6 deployment reserve:

5.4.7.2.1 The applicant may not have received resources under this policy in the preceding six (6) months;

5.4.7.2.2 The applicant must demonstrate that no other allocations or assignments will meet this need.

5.4.7.2.3 Exceptionally for this IPv6 reserve, Core DNS Service providers as defined in 5.6.4.4.2 will also include ICANN sanctioned African ccTLDs operating in the AFRINIC service region.
=========

We heard some resistance about allocation from this reserve to Core DNS services providers. Shall we remove this category ?

Thanks

—Alain


> On 3 Aug 2017, at 11:31, Andre van Zyl <vanzyla at bcxcomms.net> wrote:
> 
> Hi Owen,
> 
>> 
>> Not at all… If you want to write a policy that resolves this issue without the other baggage and problems present in this policy, I would support a clean policy designed to address that issue and make space available to ANYONE specifically for IPv6 to IPv4 connectivity/transition. In fact, I wrote such a policy in the ARIN region years ago and it is now NRPM section 4.10 in the ARIN region.
>> 
>> 
> 
> Thanks for the pointer to the ARIN policy, I hadn't actually read it before, but it was actually a very educational read for me. 
> 
> I (naively?) hadn't considered the possibility that policy could dictate what allocations could be used for, hence my fixation on trying to drive a specific use (for IPv6 deployment) through reservation and limiting the size of allocations to prevent maintaining the IPv4 status quo at the expense of future IPv6 deployments. 
> 
> Having now been elightened as to what can be done, I think that your approach is cleaner and more flexible than anything I had considered thus far. 
> 
> I think there's definitely merit in Mark's suggestion that we review other regions' policies and take what we like from them, while fixing what we don't. If anything, this exercise has made me doubly sure of it in my own mind.
> 
> Kind Regards,
> Andre
> 
> 
> 
> 
> 
> 
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd