Search RPD Archives
[rpd] Summary of proposals: IPv4 Runout Management
owen at delong.com
Thu Nov 3 23:19:57 UTC 2016
> On Nov 2, 2016, at 22:17 , Andrew Alston <Andrew.Alston at liquidtelecom.com> wrote:
> My Thanks as well,
> Owen just to address a few points in your email below that may not be clear.
> ➢ I like the idea of a reserved carve-out for critical infrastructure.
> This was deliberately excluded from the soft landing overhaul proposal as the authors believe that it is already by and large catered for. Specifically we have the IXP reservation block already, and most CCTLD’s on the continent already have space (and if they don’t, for the purposes of what a CCTLD does there is sufficient time to get the space before this kicks in). If however you feel that we need to set aside more space for other critical infrastructure, the authors would like to understand what sort of things you feel the space would be used for beyond the current reservations in place under other policies and we could then look at modifying accordingly.
CC’s are not immutable. Africa as a region probably has more changes in CCs than most. As such, I think some set-aside for these may make some sense.
Beyond that statement, I will leave it to the locals as this has little impact on me directly.
> I like the idea of a small (/12, perhaps) cutout for new organizations that are late to the party to receive up to a /24 for transition purposes.
> The authors are happy to consider this, the only question is the size of the space. The /13 allocation in the overhaul proposal was a specific number chosen based on the approximate number of new members showing up in AfriNIC each year, and this covers for new entrants. Now, as of the last time I ran my stats (which was admittedly a couple weeks back), we had approximately 1700 separate members. With that in mind though, am happy to how much space you propose to reserve for this purpose (I do think a /12 though may be too much)
I’m fine with a /12 or a /16 or just about anything in between. I will point out that your /13 calculation was based on new entrants receiving a /22.
> I do not like the idea of a large reservation for new entrants to the exclusion of the needs of existing participants.
> This is why we deliberately made it pretty small, a /13 caters for 512 members, sufficient to cover based on new member growth of approximately 2 years.
The other competing proposal, OTOH, did not. Also, note that my new entrant proposal includes a restriction that the space be used strictly for v6 transition efforts which is not part of your proposal.
> I especially do not like the idea of reserving a block of addresses for some undefined future use. Any future development that would require such a thing should be done under IPv6. There is no excuse for such development to be done in a manner that requires IPv4 addresses at this point in the evolution of the internet. We should not reward or encourage backward-thinking engineering.
> +1, and the authors of the soft landing overhall are 100% in agreement with you.
But the other competing proposal specifically favors doing this. Remember, my comments are about the overall table, not one proposal or the other.
> I think that the reservation for critical infrastructure should be from a specific block.
> See comment above about critical infrastructure – before we put something in the overhall policy we would want an *exact and exhaustive* list of what is covered under it and some justification as to the amount of space being allocated. Considering that IXP space is already catered for under another policy, the authors simply do not see the need to block out an entire /12 for this purpose (though if we have an exhaustive list of everything that is critical infrastructure we can run some actual hard statistics and come up with a proper reservation number). We have been very careful in the numbers allocated in the overhall policy to be able to justify with hard data as to why we came up with them, rather than picking arbitrary numbers, so we’d like to be able to do the same if we allocate space for critical infrastructure.
I would propose that it include IX, in-region ccTLD, and possibly some region-specific gTLDs top-level authoritative nameserver anycast prefixes. I would specifically preclude general addresses and/or management addresses for such nameservers as those should be done in IPv6 these days.
> I think it would be reasonable, if there is need, for the new entrant block to be comprised of fragments totaling a /12 equivalent rather than necessarily blocking out a specific /12.
> The authors agree – we don’t see a need for contiguous allocations here.
> I do not think that reclaimed space should be reserved for new entrants. Rather, I would prefer to see one of two approaches taken to reclaimed space:
> 1. An annoucement is made on relevant mailing lists that the space has been received and applications will be accepted beginning at a
> certain date and time. Such date and time to be not less than 14 days after the announcement is sent out.
> 2. A waiting list of unmet requests is created and the space is offered to those requestors on the waiting list on a FIFO basis.
> The authors here are prepared to look at this – but have a preference for option 2, where FIFO is strictly based on pre-approved requests from a waiting list. This avoids the situation that we currently have where FIFO is impractical because larger allocations take longer than smaller allocations and the argument then arises, does everyone wait while the queue is dealt with in a FIFO manner. Would you be ok with saying that should there be no waiting list and space comes back, it can be moved into the new entrant pool?
Not really, as that’s exactly what the proposal already says which I was objecting to. My assumption in proposing option 2 was that you would go through the normal approval process with AfriNIC and when you were approved, if they could not fulfill your request from inventory, that approved request would then be placed at the end of the current waiting list. As space comes back, each entrant on the waiting list is given the space requested, if available. If there is not sufficient space to fulfill their request, each entrant is then given the option of accepting the available space (which would complete their request and remove them from the waiting list with a “partial fill”), or passing on the space available and remaining on the list. I believe this overcomes your concern about head of line blocking.
> If we are to have a new-entrant block (I consider this optional, but desirable), it should be strictly for purposes of providing the addresses needed for transitional technologies (CGN, 6rd, etc.) and we should not allocate more than a /24 to any single new entrant. Multiple new entrants under common ownership should be treated as a single new entrant in most cases.
> The authors hesitate to tell anyone what their space can be used for, and believe this runs contrary to how the RIR’s have always operated, that being that needs based justification is based on an entities need for globally unique address space, and does not dictate any specific technological use of that space. The authors do agree with the second sentiment above however about new entrants under common ownership, the only issue here is actually being able to verify this.
The RIRs have always operated in a place where there was a free pool. There is precedent for what I propose in ARIN NRPM section 4.10.
Today we are talking about policies to deal with a situation where IPv4 no longer has a free pool and just as we have placed limits on what can be done with space in the critical infrastructure blocks, I think it is perfectly reasonable to reserve any space which is held away from existing members in favor of newcomers to a standard that requires them to use it strictly for transitional needs and not as a “business-as-usual allocation”.
Indeed, these transitional allocations are available not only to newcomers in the ARIN region and perhaps that is worthy of consideration as an alternative here as well.
>> On Nov 2, 2016, at 13:49 , Dewole Ajao <dewole at forum.org.ng> wrote:
>> Good day,
>> As indicated in an earlier email, please take some time to view and comment on https://goo.gl/FDLmZF with a view toward fine-tuning and producing an improved IPv4 runout management plan.
>> Thank you.
>> Dewole Ajao
>> PDWG Co-Chair
>> RPD mailing list
>> RPD at afrinic.net
> RPD mailing list
> RPD at afrinic.net <mailto:RPD at afrinic.net>
> https://lists.afrinic.net/mailman/listinfo/rpd <https://lists.afrinic.net/mailman/listinfo/rpd>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the RPD