[address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation"

On 11/14/11 11:52 PM, Nick Hilliard wrote:
> On 14/11/2011 21:55, Leo Vegoda wrote:
>> Where does the /26 come from? Or to put it another way, assuming the
>> basis for allocation policy is justified need, what need is considered
>> so universal that no justification is required?
>
> apparently 6rd.  Or the latest transition mechanism, except that it's such
> a good address justification mechanism that you don't even need to mention
> which transition mechanism you're planning to use, or even if you are
> planning to use a transition mechanism at all.

Dear Nick,

Yes, exactly. Many "early" adopters knew no better and got their /32 in 
order to start testing IPv6 and today they would need much more to take 
advantage of some addressing ways that IPv6 can offer - and we had some 
of them expressing this thought at RIPE62, RIPE63 and here on list.

I know I'm repeating myself, but probably we should try to "unlearn" all 
the speed-bumps we put into IPv4 addressing policy in order to slow down 
depletion and start distributing IPv6 space as needed, adapting the 
defaults to the feedback from operational environment and community.

>
> I'm struggling to understand how this proposal meets the Conservation
> section of the RIPE IPv6 allocation policy:
>
> "Although IPv6 provides an extremely large pool of address space, address
> policies should avoid unnecessarily wasteful practices. Requests for
> address space should be supported by appropriate documentation and
> stockpiling of unused addresses should be avoided."

I would understand this as "do not give /20 to a LIR with 10 users."

Note the word "should", therefore this must be taken just as a guidance, 
not a must.

>
> It hardly takes much effort to mention to the RIPE NCC that your LIR is
> applying for a /29 instead of a /32 because it intends to implement 6rd,
> does it?

Then everybody can mention that they are about to deploy 6RD ;) We 
thought of this, but this just introduces unnecessary cycle in the process.

> While I don't have a major problem with giving 3 extra bits of
> space to implement 6rd, I do have a major problem with:
>
> 1. making this the default configuration, even for those LIRs who have no
> intention of ever deploying 6rd or any other equivalent transition mechanism,

/29 for legacy allocations is reserved. Some LIRs would lower 
operational costs if they could use it (as nobody else could use that 
space). For latest allocations on binary chops, large quantities of 
space are in between allocations and likely in our lifetime we will not 
come to less than /24 or /25 in between the allocations. Fail to see the 
problem giving LIRs more space by default.

>
> 2. removal of the requirement to specify 6rd/other mechanism to justify the
> extra space, and

Yes, removing extra cycle...

>
> 3. allocating /26 by default.  102 bits of address space is obscenely
> wasteful because it is very significantly more than most LIRs will ever
> require in the lifetime of the universe (yes, I have worked out the scales
> here).

Agree.

>
> Look, I don't mean to sound like a party pooper, but let's not lose the run
> of ourselves here.  6rd has very limited deployment at present, and while
> it shows a lot of promise as a potentially useful transition mechanism,
> it's not yet at the stage where we should feel tempted to shower LIRs with
> ridiculous quantities of address bits just because we're feeling a bit
> inadequate about current ipv6 uptake.

Broadcom revealed that in new chipset for CPE IPv6 and 6RD are HW 
accelerated. Major vendors are offering 6RD core boxes and many 
operators are testing them. Let's do that properly, if it's unavoidable. 
6RD is not the best mechanism ever invented, but making it more 
complicated and expensive with multiple-6rd-domains because of lack of 
IPv6 space makes operational life even more complicated.

>
> I'd like to suggest that 2011-04 be changed so that LIRs can expand their
> default /32 to a /29 iff they document a requirement for providing 6rd /
> {another specified ipv6 transition mechanism which requires similar bits of
> address space} to end-users.  Otherwise, a /32 will be assigned by default,
> and the RIPE NCC can continue on with their current binary chop allocation
> strategy.

Again, so everybody can write into their request "we'll deploy 6RD". 
This is not solving anything. Please, start unthinking IPv4...

RIPE-NCC can continue with exactly the same binary chop even if 2011-04 
gets implemented.

Cheers, Jan