[address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)

Reply inline.
Dne středa 6. února 2019 14:35:22 CET, Daniel Karrenberg napsal(a):
> 
> On 06/02/2019 11:23, Martin Huněk wrote:
> > 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).
> 
> That is where the implementation would become very complicated since it
> needs to be perceived as 'fair'. I see no good reason for this complication.

Not necessary. Simple question would do: "We have got 3x /24 right now or /22 in 3 months. Do you want to get them right away or do you want to wait for whole /22?". RIPE NCC knows where next prefixes would leave 6 months quarantine, so at least a first few LIRs on the list would know where to expect IPv4 prefixes.

It could be seen as a complication of process, but it is important to mention that we are talking about one LIR per each batch of returned IP space. And even that could be automated trough LIR portal.
> 
> > ... Keep /22 possibility so the 
> > complete runout of IPv4 won't be postponed.
> 
> See above. I do not see the point about 'complete runout'. We *have* run
> out already. This is about the very very tail end.

What I'm afraid of is pressure for further deaggregation of those last /24s. Even now in the mailing list there was opinion that just one /24 is useless because you can't assign from it to another entity. Not talking about fact that if you have same amount of LIR on waiting list when everybody wants 4x more, the waiting list is 4x longer time-wise. Longer list = less probability of getting IPv4 ~ no more IPv4 -> had to go for IPv6.

If you have /22 you can do that, if you could have /22 but you have chosen /24 (now instead of waiting for /22) - you could have done that and if there won't be enough IPv4 for you that would be just a fact and there would be nothing to do about it. So there won't be such pressure for further deaggregation. At least if IANA won't distribute to RIRs smaller prefixes anyway.

And just why is such deaggregation problem for me? Because we would be spending even more RAM and computation effort on "walking dead" IPv4. And if we start to allow such deaggregation we would end up on single /32 in our routing table. At least for now we all know that if we try to announce /25+ we would have reachability issues. Let's keep it that way.

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: </ripe/mail/archives/address-policy-wg/attachments/20190206/0225d856/attachment.sig>