[ipv6-wg] Re: [address-policy-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments)

Marco Hogewoning wrote:
> On Sep 6, 2010, at 4:06 PM, <kpn-ip-office at kpn.com> <kpn-ip-office at kpn.com> wrote:
>
>   
>> I have some questions about the proposal
>> Question 1:
>> Why was chosen for "SUB-ASSIGNED PA" and not for "SUB-ALLOCATED PA" or even "LIR-PARTITIONED PA", which according to my understanding would be more in line with the IPv4 world and the proposal states it "...is largely designed based on the current IPv4 practice..."?
>> Besides that, ASSIGNED PA is the 'lowest status' in the IPv4. Using the term SUB-ASSIGNED PA higher in the hierarchy than ASSIGNED PA in IPv6 world might only create confusion.
>>     
>
> It has to be unique so we can implement some basic rules on wether the assignment-size attribue is mandatory, other then that the exact naming can be anythingmwe like. I picked this becuase it makes sense to me.
>   

I think the term "SUB-ASSIGNED PA" may cause some confusion in the RIPE
Database. For the last 10 years or more we have been enforcing policies
that imply sub assignments are not allowed. Although the term 'sub
assignment' is not used in the IPv4 policies it has often been used when
discussing the business logic of the RIPE Database.

The term "SUB-ALLOCATED PA" may be easier to understand. It's meaning in
the IPv6 world would be slightly different to the same status value in
the IPv4 world. But both can be partly described as "a sub set of an
allocation from which assignments are made".

>   
>> Question 2:
>> Also, when putting such an inetnum object on the RIPE database, would it require approval from the RIPE NCC if the (initial) sub-'assignment' exceeds a /48 (in relation with RIPE-481 chapter 5.4.2)?
>>     
>
> No you shouldn't, probably as long as assignment-size > /48
>
>   
>> Question 3:
>> In IPv4 world (and policy document) the purpose of registration is "... to ensure uniqueness and to support network operations." (RIPE-492 4.0)
>>
>> I realise that this sentence is not in the RIPE-481 document, so maybe this is out of order/scope, but in creating a 'pool' possibility we explicitely choose to not register inetnum information on the End User level. Does this not make "support network operations" a lot harder?
>>     
>
> I don't think so, especially since there is no requirement to register at all at the moment. So I can't tell if it's hijack r the space is actually in use.
>   

Having spent many years looking at data from many LIRs in the RIPE
Database I see two business models that are commonly used. One is to
aggregate many individual customers into an assignment block. Create one
INETNUM object with status ASSIGNED PA covering this range of addresses
and reference contacts from the LIR. The other is to document every end
user in the RIPE Database. Create an INETNUM object with status ASSIGNED
PA for each customer, even if it is only for a single IP address, and
reference a PERSON object representing the customer.

This policy proposal allows both these models to be used by LIRs in the
IPv6 world. The SUB-ASSIGNED PA INET6NUM object is the equivalent of the
aggregated ASSIGNED PA INETNUM object. If the LIR chooses to document
all their end users in the RIPE Database they can also create ASSIGNED
INET6NUM objects for each end user under the SUB-ASSIGNED PA. So
whatever model an LIR uses now for their IPv4 customers in the RIPE
Database, they can continue to use the same model as they expand into
the IPv6 world.

Regards
Denis Walker
Business Analyst
RIPE NCC Database Group

>   
>> Question 4:
>> In IPv4 world, there are also LIRs that use this idea (registering a pool of addresses from which assignments are made to a number of different End Users) . But an extra status has not been required: on approval from RIPE NCC the LIR registers an inetnum with status "ASSIGNED PA". Why would an extra status be required in IPv6 world?
>>     
>
> This one I don't understand. As far as assignments to end-users, it's usually implicit to be a /32. If any other cases exisit I wonder wether they are valid at all, but I'm not an IPRA. 
>
>   
>> With kind regards,
>>
>>
>> ir. A.W. (Andries) Hettema
>> KPN IP-Office
>> kpn-ip-office at kpn.com
>> +31 70 45 13398
>>
>>
>> -----Oorspronkelijk bericht-----
>> Van: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] Namens Sander Steffann
>> Verzonden: vrijdag 3 september 2010 21:38
>> Aan: ipv6-wg at ripe.net
>> CC: Marco Hogewoning; Nick Hilliard; address-policy-wg at ripe.net Working Group
>> Onderwerp: Re: [address-policy-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments): discussion in the IPv6-WG mailing list
>>
>> Hi Marco,
>>
>>     
>>> Oh and could people at least cross-post ?
>>>       
>> Sorry. Probably my fault.
>>
>>     
>>>>>> The only issue I have is that it appears to mandate that all assignments makes from a SUB-ASSIGNED PA block are exactly the length specified.  This means that if the ISP has policies of, say,  /56 for most customers but /48 for some, while at the same time wanting to implement some form of per-PoP prefix aggregation, it means assigning multiple blocks per aggregation point, one per assignment size.
>>>>>>             
>>>>> Allowing multiple "assignment-size:" fields might solve that.
>>>>>           
>>>> No it won't, you have a /40 with assignment size /56 and /64 and then how to specify which customer has what. Can't we solve this by allowing more specifics ?
>>>>
>>>> The original thought was to just create multiple entries, one for each assignment size. But we could allow for something like:
>>>>
>>>> bla:://40 -> assignment size /48
>>>> bla::1/48 -> assignment size /56 
>>>>         
>> After thinking about it, this seems to be the best solution.
>> Sander
>>
>>     
>
>
>