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

[Sander Steffann]

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 :-)

>>> 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...

>>> 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...

Thanks!
Sander