2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments): discussion in the IPv6-WG mailing list
[Apologies for duplicate emails] Dear Colleagues, A new policy proposal, 2010-06, "Registration Requirements for IPv6 End User Assignments", was published to the IPv6 Working Group mailing list today. The proposal can be found here: http://www.ripe.net/ripe/policies/proposals/2010-06.html The proposers would like to draw your attention to the proposal and invite you to join the discussion about it on the IPv6 Working Group mailing list: http://ripe.net/ripe/maillists/archives/ipv6-wg/2010/index.html You can email the working group at: <ipv6-wg@ripe.net> Kind regards Emilio Madaio Policy Development Officer RIPE NCC
On 01/09/2010 15:21, Emilio Madaio wrote:
A new policy proposal, 2010-06, "Registration Requirements for IPv6 End User Assignments", was published to the IPv6 Working Group mailing list today.
I think I like this policy, mostly. 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. Is this intentional? Nick
Hi,
A new policy proposal, 2010-06, "Registration Requirements for IPv6 End User Assignments", was published to the IPv6 Working Group mailing list today.
I think I like this policy, mostly.
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. Sander
On 03/09/2010 16:30, Sander Steffann wrote:
Allowing multiple "assignment-size:" fields might solve that.
perhaps. But the beauty of only allowing a single size is that the RIPE NCC can multiply the number of assignments by the value of the assignment-size: field to find out the H/D ratio. I'm not trying to argue out both sides of my mouth here, btw. I'm just trying to understand what the intention of the proposal is, and whether the proposal needs to be clearer in this regard. Nick
I guess it really depends on what you'd want to consider as more important; ease of administration or aggregation. The policy makes the assumption of large amounts of end user assignments being made - if you want out both /48 and /56 from a single PoP and you're going to do both in any significant quantity, I'd personally choose to use separate blocks for the /56 and the /48 assignments to allow for easier recycling. Then those blocks can have their own separate entry in the database, each with a single assignment size. If you need to re-hash block sizes at a later point, you can always change to a larger number of smaller blocks in the database. Database entries are (relatively) cheap. Best Remco
-----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg- admin@ripe.net] On Behalf Of Nick Hilliard Sent: vrijdag 3 september 2010 17:35 To: Sander Steffann Cc: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments): discussion in the IPv6-WG mailing list
On 03/09/2010 16:30, Sander Steffann wrote:
Allowing multiple "assignment-size:" fields might solve that.
perhaps. But the beauty of only allowing a single size is that the RIPE NCC can multiply the number of assignments by the value of the assignment-size: field to find out the H/D ratio.
I'm not trying to argue out both sides of my mouth here, btw. I'm just trying to understand what the intention of the proposal is, and whether the proposal needs to be clearer in this regard.
Nick
This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383.
On 03/09/2010 16:43, Remco van Mook wrote:
I guess it really depends on what you'd want to consider as more important; ease of administration or aggregation. The policy makes the assumption of large amounts of end user assignments being made - if you want out both /48 and /56 from a single PoP and you're going to do both in any significant quantity, I'd personally choose to use separate blocks for the /56 and the /48 assignments to allow for easier recycling. Then those blocks can have their own separate entry in the database, each with a single assignment size. If you need to re-hash block sizes at a later point, you can always change to a larger number of smaller blocks in the database. Database entries are (relatively) cheap.
So the "assignment-size:" really means maximum assignment size rather than exact assignment size? Yes, certainly if you're large enough, you would go for separate blocks for /48 and /56 anyway. However, smaller operations may carve them from the same block for whatever reasons. Nick
Nick Hilliard wrote:
So the "assignment-size:" really means maximum assignment size rather than exact assignment size?
There's certainly nothing stopping you from doing that - however it'll leave you with some explaining to do by the time you want your next block, because the smaller sub-assignments might not be reflected in HD ratios.
Yes, certainly if you're large enough, you would go for separate blocks for /48 and /56 anyway. However, smaller operations may carve them from the same block for whatever reasons.
As I said, database entries are relatively cheap - you can still use a single routable block and use multiple database entries to describe that single block, using separate entries for separate prefix sizes. If an operation is of such a size that they don't have enough customer volume in a single block size to be able to aggregate, they're probably down to using individual database entries for individual customers anyway. You could even use overlapping database entries, where the 'most specific' entry wins. This way you can define blocks of /56s in a block that would otherwise have /48s, for example. Remco This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383.
On 03/09/2010 17:15, Remco van Mook wrote:
Nick Hilliard wrote:
So the "assignment-size:" really means maximum assignment size rather than exact assignment size?
There's certainly nothing stopping you from doing that - however it'll leave you with some explaining to do by the time you want your next block, because the smaller sub-assignments might not be reflected in HD ratios.
I'm concerned that unless this is spelled out, it creates a hole for unsuspecting LIRs to fall into. Think of how much future LIR and IPRA frustration could be prevented by making a one-line note in the "Usage" section about what will happen if you mix-n-match your assignment sizes! Nick
On 3 sep 2010, at 17:30, Sander Steffann wrote:
Hi,
A new policy proposal, 2010-06, "Registration Requirements for IPv6 End User Assignments", was published to the IPv6 Working Group mailing list today.
I think I like this policy, mostly.
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 MarcoH
Oh and could people at least cross-post ? On 3 sep 2010, at 21:13, Marco Hogewoning wrote:
On 3 sep 2010, at 17:30, Sander Steffann wrote:
Hi,
A new policy proposal, 2010-06, "Registration Requirements for IPv6 End User Assignments", was published to the IPv6 Working Group mailing list today.
I think I like this policy, mostly.
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
MarcoH
MarcoH
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
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. 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)? 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? 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? 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
participants (6)
-
Emilio Madaio -
kpn-ip-office＠kpn.com -
Marco Hogewoning -
Nick Hilliard -
Remco van Mook -
Sander Steffann