As I understand the current proposal and the NCC's impact analysis, implementation of this proposal would necessarily mean that the resulting IXP pool would be at best two disjoint /16s, at worst one /16 plus a bunch of smaller fragments scattered all over the address space. That'd be a shame, in my opinion. Mmmh. Marco, can you comment on whether this is an implementation thing at the NCC, or whether you'd need a formal statement in the policy text to make this happen?
(While it's all just numbers, some numbers look more familiar than others, so having all IXP space "in one block" is a bit easier on "oh, these numbers look IXPish" - so I can see that it would be nice) Yes, this is an implementation thing. While the IPv4 Policy requires
Hello Gert and colleagues, On 09/08/2019 21:43, Gert Doering wrote: that we set aside a /16 for unforseen circumstances, it doesn't specify the range or that it must be a contiguous block. At RIPE 77, Andrea Cima suggested that this (currently contiguous) /16 could be replaced with an equivalent of /23s and /24s as we near IPv4 runout: https://ripe77.ripe.net/wp-content/uploads/presentations/71-Andrea_Cima_RIPE... There was general support for the idea, though some questioned the intent of doing this to create more convenient /22 allocations. Now with this proposal, we plan to replace the currently-reserved 185.0.0.0/16 and use this for the IXP pool if this proposal reaches consensus. So Tore's suggestion would be achieved. It should be noted that for this to happen, there must be at least a /16 of regular space in our remaining pool when rough consensus is reached, to allow us to make the swap. The IPv4 Policy is clear that this reserved space must be used for IPv4 allocations as per section 5.1. Kind regards, Marco Schmidt Policy Officer RIPE NCC