<html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hi Mathew, Thanks for your question. As previously mentioned on the mailing list, LIRs can return unused previously-allocated IPv6 blocks if they believe their initial deployment plans require more than a /29. If a bigger allocation size is justified, the RIPE NCC will allocate a new range with the according reservation to allow for future aggregation. If an LIR has already started to deploy IPv6 from their current allocation and would like additional IPv6 space, the subsequent allocation policy applies: <a class="moz-txt-link-freetext" href="https://www.ripe.net/publications/docs/ripe-641#subsequent_allocation">https://www.ripe.net/publications/docs/ripe-641#subsequent_allocation</a> Where possible, the allocation will be made from an adjacent address block. I hope this answers your question. Best regards, Ingrid Wijte Registration Services Assistant Manager RIPE NCC <div class="moz-cite-prefix">On 13/07/15 12:31, Mathew Newton wrote: </div> <blockquote cite="mid:AMSPR05MB2791F3A37FD3F421563AC39979C0@AMSPR05MB279.eurprd05.prod.outlook.com" type="cite"> <pre wrap="">Tore, </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> The 2015-03 proposal might still help/apply if you view the situation as being that the customer has not *outgrown* their /29 allocation (and hence needs consideration under the subsequent allocation policy) but rather that they have effectively *ordered the wrong size* in which case they could return the /29 and get a /28 in return under the new initial allocation criteria. If the /28 is able to encompass the first then this obviously carries the benefit of not requiring any renumbering. This is just speculation though and so, for clarity of understanding, it would be good to hear how RIPE NCC would see things operating in such a scenario... Mathew </pre> </blockquote> </body> </html>