[Apwg-ipv6-papi] The Picture / Re: first draft?

[Daniel Stolpe]

On Wed, 14 Aug 2013, Sander Steffann wrote:

> Hi,
>
>>>> 3. Is it ok to consider that everyone who makes an allocation is an IR?
>>>
>>> I'm not happy with the distinction between Allocate and Assign in the current text. It creates different colours again. If my ISP assigns addresses to me and I want to host my cousins server in my address space then I violate the policy as that would be a (very small) sub-assignment. The whole idea of the PAPI proposal was to fix this.
>>
>> true, but the RIPE NCC has always considered assigned address space as in use, (sub-)allocated address space is only considered to be used if assignments/aggregations are registered within.
>>
>> An additional problem I would see, if we remove the differences, is.. what if an LIR makes an allocation to a customer. How to calculate the HD-ratio if not by looking at which assignments/aggregations are registered within?
>>
>> If your ISP assigns address space to you and you need to host a server, you can ask him to change the status of the address space to sub-allocated and then you can make assignments, one to yourself and one to your cousin.
>
> And the majority of ISPs won't make that change for you because it 
> deviates from their normal workflow... Make everything an allocation. 
> The current policy already allows for AGGREGATED-BY-LIR which allows for 
> registering a bigger block without explicitly putting all the 
> assignments in the database. That already prevents the HD-ratio to be 
> calculated from the information in the database. Lets use that 
> structure. Let the LIR allocate a big block to another organisation, let 
> that organisation allocate smaller blocks (/48? /56? etc) to other 
> organisations, let those allocate even smaller blocks to others etc. 
> Don't limit the recursion level :-)  Limit what someone may allocate to 
> a different entity/organisation based on the current rules (/48 per 
> end-site). If a block bigger than a /48 is necessary then documentation 
> has to be provided. Sub-allocations don't exist in current IPv6 policy 
> but we can define that they are allowed but that the HD-ratio still only 
> looks at the end-sites. But don't prevent those end-sites from 
> allocating something to their cousin.
>
> Something like that anyway :-)

I like that. We will have to transform it into a policy text somehow. :-)

>>>> 4. Is it ok to consider that an LIR should not make a sub-allocation
>>>> smaller than /48?
>>>
>>> I think this is a bad idea. The operator decides on how to run his network, and introducing artificial limits should only be done as a last resort.
>>
>> the idea, as far as I understand, is to try "not to encourage assignment of /64 or single addresses to end users".
>>
>> If an LIR sub-allocates something something smaller than a /48.. let's say a /56, and then the customer starts assigning a /64, then we will not reach this goal.
>>
>> I was thinking that if someone needs to sub-allocate, a /48 should be the minimum.
>>
>> Let's continue the discussion and if you still think this limit should be removed, I'll gladly remove it :)
>
> Define sub-allocation first :-)  If I run a rack in a data centre then 
> my ISP allocating a /56 to me so that I can allocate a /60 to each of my 
> customer's servers should also be possible...

I guess we do not want to encourage assignments of /128:s but I will have 
to reread the text and think about it.

>>>> 5. Is it ok to request LIRs that make sub-allocations bigger than /32 to
>>>> send a request to the RIPE NCC for approval?
>>>
>>> That is ok, but explain the reasons.
>>
>> Well, if an LIR makes a sub-allocation larger than a /32, then I think the RIPE NCC should be the one approving the request. If an organisation needs an allocation larger than a /32 (64K /48s), then I think that an evaluation should be made.
>
> Sub-allocations should again be defined in a better way...

Yes.

Great work Elvis!

Give me a day or two and I will read the document through.

Best Regards,

Daniel Stolpe

_________________________________________________________________________________
Daniel Stolpe           Tel:  08 - 688 11 81                   stolpe at resilans.se
Resilans AB             Fax:  08 - 55 00 21 63            http://www.resilans.se/
Box 13 054							      556741-1193
103 02 Stockholm