Hi Jens, * Opteamax GmbH
> for a customer, I had a request for a /28 opened recently and were > offered to start with a /29 and maybe resize it to /28 depending on > outcome of 2015-03. I asked back if "resize" means new allocation so > renumbering and received the following reply for RIPE-Staff: > > > We actually reserve 3 bits for each allocation so in future if > > needed your user would have access up to a /26. You should ask that IPRA should re-read 2015-03. If your customer is allocated a /29, the new allocation criteria currently proposed in 2015-03 can simply *not* be used to "resize" it to a /28. This is, as I've mentioned earlier, due to the fact that 2015-03 only changes the *initial* allocation criteria. If already allocated a /29, your customer would need to request a *subsequent* allocation in order to obtain a /28, but as the subsequent allocation criteria is not changed by 2015-03, it won't be of any help as far as your customer's concerned. The Impact Analysis says: «It is important to note that the suggested policy change could also have impact on the evaluation of subsequent IPv6 allocation requests. LIRs that request an initial allocation under the proposed new assessment criteria might find it difficult to reach a sufficient HD-ratio in the future, as a significant amount of address space will be reserved for network structuring and future growth. Meeting the specified HD-ratio is required to qualify for a subsequent IPv6 allocation.» If your customer would qualify for a /28 under the 2015-03 criteria, I'd advise patience - have your customer wait until 2015-03 is implemented, at which point you can submit an *initial* allocation request for a /28. > I just downloaded > ftp://ftp.ripe.net/ripe/dbase/split/ripe.db.inet6num.gz and grep'ed for /29 > > $ grep "/29" ripe.db.inet6num | sort > > I did not validate each and every line, but paged thru the output and it > actually seems that the allocations made are all with a following > reserved space that they can be grown upto /26: That is only the case if the allocation was a /29 to begin with. If it started out as a /32, and was extended to a /29 (most likely under the 6RD policy), then it can be expanded no further. Matthew's allocation, 2001:40c8::/29, is an example of this - the covering /28 contains other unrelated allocations: $ whois -h whois.ripe.net -- -m 2001:40c8::/28 | egrep '^(inet6num|netname):' inet6num: 2001:40c0::/32 netname: CH-SAFEHOST-20040726 inet6num: 2001:40c8::/29 netname: UK-MOD-20070802 Tore
