Hi, just a small reaction to what you have written (in line). Dne středa 6. února 2019 10:39:24 CET, Daniel Karrenberg napsal(a):
After reading and thinking I arrive at the following principles:
a) It is not tenable for the RIPE NCC to stop allocating IPv4 addresses as long as it has blocks that are useful to route packets.
Note: As an individual I would very much like to just stop with this silliness. However I do not think this is tenable for us as a community.
No problem here. I would be one of them, but I know that there won't be consensus.
b) Once the pool decreases below that threshold the RIPE NCC has to maintain a waiting list in order to establish a sequence in case space becomes availble. Reason: see (a)
I also agree with that.
c) It is not tenable for the RIPE NCC to require the first LIR on the waiting list to wait for more address space than a minimal usfeful block to accumulate.
Here it starts. I would say get such a LIR what you have got (to /22 of course). Even by means of multiple /24s. But not blocks smaller than /24, as it would be useless. Maybe let them decide if they would like to wait for whole /22 where there would be less then 4x /24 (in that one case).
d) The length of the waiting list and other practicalities should be secondary considerations after these principles above. For instance, the RIPE NCC can always recover the costs incurred by the process from those using it.
No dispute here.
1) Motivate the choice for /24 in terms of being the smallest block useful to route packets considering current routing practice.
Also no issue here. Motivate yes, require no. Keep /22 possibility so the complete runout of IPv4 won't be postponed.
2) Explicitly mention the non-goals of the policy as discussed.
I think that those were discused here in the list. I don't think that it should be written in the policy itself.
3) Keep in mind our good experience with using concrete dates for policy changes. Consider to make the change on a specific date. This is more predictable than an event sometime in the future. "Run Out Fairly" worked pretty well. Specifically why not just say "This polixy into effect on September 1st 2019"?
You cannot be sure where it would happen.
4) The policy could be made more adaptable to future scenarios. This would prevent more ad-hoc policy changes which are a pain and do not look very professional to the world outside RIPE. Maybe the policy could be 'parameterised' so that the community can decide to change parameters rather than re-write the policy text.
Sure, add there the waiting list if needed, but do not change the /22. This way it will be consistent.
4a) Consider the possibility that future routing practice may change the longest useful routing prefix away from a /24 as Randy alluded to. This should be a parameter.
I'm strongly agains that. Let's keep there explicitly /24 as the longest routable prefix. Allowing a longer one would give a signal to other RIRs that it is fine with us. That would bring yet another deagregation so more junk in routing tables. I'm not sure that we would all agree on changing our BGP filters to allow that. And if so, someone whom will be given such small pool would have problem with reachability.
4b) Consider the possibility, however unlikely, that the RIPE NCC receives a significant amount of address space to re-distribute. Would this policy still be supported by the community in this event? Should the allocation size be a parameter that can increase above the <smallest usable prefix> either by community choice or automatically if a certain pool size is exceeded?
If you keep there /22 and /24 as an option, than there would be no problem.
4c) What happens down the road when IPv4 really becomes legacy? Can we make the policy applicable even then? Would (4) and (5) above do the trick?
Then it would be wise to pass a policy that would say that. Like: "IPv4 is considered to be a legacy protocol. RIPE would not provide any allocation/ assignment of IPv4 resources." Or what ever.
5) Maybe mention explicitly that one has to be a LIR in good standing to be on the waiting list.
More LIRs on the list means smaller chance that anyone would get an address pool. So let them wait there, it just as easely may work as a motivation torward IPv6. Like: "Just look at that list! IPv4 is gone for good." Martin