[address-policy-wg] About the /22 allocation limitation
- Previous message (by thread): [address-policy-wg] About the /22 allocation limitation
- Next message (by thread): [address-policy-wg] About the /22 allocation limitation
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Sander Steffann
sander at steffann.nl
Wed Apr 16 13:06:11 CEST 2014
Hi Tore, > Also for the sake of the argument I'll make the assumption that the > reserved pool is activated when it contains a /10, both because that's a > figure you've mentioned earlier, and also because waiting until it > contains a /9 will in all likelihood mean it will sit there inactive for > years, and that won't help anyone either. > > First, let's try with a max allocation size of /22. Then there would be > 4096 /22s in the pool, enough for all of the LIRs you want us to take > care of. Something about this worries me. I am afraid we will end up with more 'types' of LIRs: - the old ones that could request whatever they needed - the ones that started just before runout who have one /21 and one /22 - the first 4096 that started just after runout who have two /22s - the later ones that have one /22 The first 4096 of last category could potentially get another /22 when/if the pool reaches a /10 again, but as you say this will take years. This doesn't feel right. If we make a policy to give more IPv4 addresses to the LIRs that only have one /22 then it should be: - equal for all of them - sustainable for a long time If we can do this then I don't see a problem, but in order to do this the returned pool has to be able to grow to (almost) a /8 because otherwise we won't be able to give every LIR with one /22 their second /22. And that will create unfairness again... Cheers, Sander
- Previous message (by thread): [address-policy-wg] About the /22 allocation limitation
- Next message (by thread): [address-policy-wg] About the /22 allocation limitation
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]