[address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size)

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