[address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations)

Sascha,

I think we broadly agree, actually :-)

On 23 May 2007, at 12:07pm, Sascha Lenz wrote:

[...]

>>> - A recurring fee of 100EUR/y is charged from the RIPE NCC directely
>>>   or via the handling LIR
>> As you noted elsewhere, fee schedule decisions belong to the  
>> membership.
>
> yes, i did. This is over-simplified to state my point WHAT a policy  
> needs to look like *in the end*.

Fair enough and I agree that a contract for the assignment is a very  
important element.

>>> - The assignment is at least a /48 from a dedicated supernet-block
>>>   which clearly identifies it as Provider Independent Prefix
>>> - A shorter prefix may be assigned if the end-site provides a  
>>> network
>>>   plan and possible contracts with suppliers that hint that a /48
>>>   prefix might not contain enough subnets for the planned lifetime
>>>   of the assignment.
>> Hint? If prefixes shorter than /48 should not be the default  
>> assignment then I think we need more than a "slight or indirect  
>> indication or suggestion" that more than a /48 is required. If I  
>> just need to hint that I might possibly need more than a /48 over  
>> the next 15 years to receive a /44, /40 or /32 then the policy is  
>> utterly broken.
>
> Facts:
>
> - The PA policy (http://www.ripe.net/ripe/docs/ 
> ipv6policy.html#assignment_size)
>   doesn't really say anything specific either, and AFAIK there hasn't
>   been a single End-User Request for </48 yet(?).

I agree that the PA policy is equally flawed. I remember several  
requests for more than a /48 PA assignment. In most cases though,  
people had misunderstood the difference between an assignment and an  
allocation and they really need a sub-allocation which does not need  
approval by the RIPE NCC.

>  If the RIPE NCC thinks it can provide input on what they need here
>  or experience like how they deal with </32 PA requests for very large
>  sites, i'm happy to hear them out. Should be similar to what </48
>  end-user requests should look like.
>  I don't want to make a difference between PI and PA assignment
>  requirements here in the end, that's my plan at least.

I think using the same criteria to evaluate PA and PI requests would  
be useful and fair.

> - It's vague, but it's always stressed that the RIPE NCC hostmasters
>   usually know what they do and have the experience to tell if someone
>   provided the correct amount of information for a given request.
>   Why should that be different for IPv6 PI now?

The difference is that the IPv4 using community has over a decade of  
experience and plenty of documents describing what is and is not  
efficient. There isn't much IPv6 deployment experience and what is  
considered efficient usage of a /48 isn't documented (I think).

>   Isn't some kind of contract or bills for equipment like i suggest  
> here
>   enough? That's what i'm usually asked to provide to the NCC if i
>   request some biiiiiiiiiig IPv4 assignment/allocation at least.
>
> PROBABLY the PI and PA policy needs something like "utilisation  
> within a 2year term" statement or so similar to the IPv4 assignment  
> policy; that is correct. But i intentionally left that out here  
> since it's not in the  PA policy either. (RFC3177 doesn't say  
> anything about a specific timeframe either AFAICR).

I agree that something like 'x subnets used in y years' would work. I  
don't know what x and y should be, though. When we have that I will  
know how many thousand subnets I have to use before my network  
qualifies for a /47. That will be genuinely useful for people  
deploying IPv6 networks.

My concern isn't the tools the RIPE NCC will use to determine that  
someone qualifies. They will use whatever evaluation techniques are  
appropriate and I don't think the policy needs to worry about them. I  
just think the policy needs to let them know what they are measuring.

[...]

> I actually want to prevent big assignments to be granted just  
> because some bad network design. But how the hell should we predict  
> what's bad and what not here in writing? Happy to hear suggestions  
> how to prevent this. I personally think that this can only be  
> solved with clue++; at the RIPE NCC Hostmaster level in the end,  
> not by a rigid policy.

I'm not worried about the RIPE NCC's clue level - they do well there.  
I just want them to be given the tools they will need when they have  
to justify their decisions.

Regards,

-- 
Leo Vegoda
IANA Numbers Liaison