On Sep 6, 2010, at 4:06 PM, <kpn-ip-office@kpn.com> <kpn-ip-office@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.
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.
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@kpn.com +31 70 45 13398
-----Oorspronkelijk bericht----- Van: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] Namens Sander Steffann Verzonden: vrijdag 3 september 2010 21:38 Aan: ipv6-wg@ripe.net CC: Marco Hogewoning; Nick Hilliard; address-policy-wg@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