[address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation)

On 10/24/11 3:29 PM, Remco Van Mook wrote:
>
> All,
>
> I support the thought that LIRs should be able to get up to a /29 as an
> initial allocation with no documentation required.

Hi,

Good :)

> However, that doesn't
> mean I support the policy proposal in its current form. Here's why. In the
> current policy text, it's very clear cut that unless you provide
> documentation (which means you've thought about how to deploy), you get a
> /32. I would not want a situation where people get a /29 without thinking,
> making a mess of it and then come back. So you could get a /29 if you
> asked for it specifically, otherwise you get a /32.

Well, this part was meant to figure it out when implementing changed 
policy. My suggestion was that IPRA warns LIR that is requesting the 
initial IPv6 allocation, that /32 means different charges in the future 
than /29, so LIR can decide and get what they need.

I was warned, that this is implementation specific issue and should not 
be part of the policy.

Being said that, /32 still exists as minimum alloc size just to prevent 
someone saying "RIPE-NCC would like to pay us more" - we already 
discussed that in Dubrovnik, remember? :)

>
> So I would propose the following:
>
> Organisations that meet the initial allocation criteria are eligible to
> receive an initial allocation of /32. For initial allocations up to /29 no
> additional documentation is necessary.
>
> Organisations may qualify for an initial allocation greater than /29 by
> submitting documentation that reasonably justifies the request. If so, the
> allocation size will be based on the number of existing users and the
> extent of the organisation's infrastructure.

So, your suggestion is to give out /32 by default for clueless, but if 
someone requests more (up to /29) - fine, here it is.

Hmm... looks like this makes sense.

What others think?

>
>
> --snip--
>
> And, of course, using up your /29 in one go means no additional adjacent
> reserved address space on the RIPE NCC books, but that's an implementation
> issue :)

With binary chops one must be very unlucky to get non-expansible space :)

Cheers, Jan