Re: [address-policy-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments): discussion in the IPv6-WG mailing list
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
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
Marco Hogewoning wrote:
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.
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@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
Thus wrote Denis Walker (denis@ripe.net):
Marco Hogewoning wrote:
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", [...]
[...]
One is to aggregate many individual customers into an assignment block.
It's a rather bikeshedding issue, but maybe pick AGGREGATED PA? LIR-PARTITIONED PA would also be easily understandable, but is a mouthful. :) regards, spz
On 8 sep 2010, at 15:49, S.P.Zeidler wrote:
Thus wrote Denis Walker (denis@ripe.net):
Marco Hogewoning wrote:
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", [...]
[...]
One is to aggregate many individual customers into an assignment block.
It's a rather bikeshedding issue, but maybe pick AGGREGATED PA? LIR-PARTITIONED PA would also be easily understandable, but is a mouthful. :)
I was about to come with the same suggestion. As said, the current one basically is just a placeholder as we needed something in the revision 1 document. 'AGGREGATED XX' is pretty much unique and clearly describes the whole purpose. MarcoH
On Sep 8, 2010, at 10:20 PM, Marco Hogewoning wrote:
On 8 sep 2010, at 15:49, S.P.Zeidler wrote:
Thus wrote Denis Walker (denis@ripe.net):
Marco Hogewoning wrote:
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", [...]
[...]
One is to aggregate many individual customers into an assignment block.
It's a rather bikeshedding issue, but maybe pick AGGREGATED PA? LIR-PARTITIONED PA would also be easily understandable, but is a mouthful. :)
I was about to come with the same suggestion. As said, the current one basically is just a placeholder as we needed something in the revision 1 document.
'AGGREGATED XX' is pretty much unique and clearly describes the whole purpose.
How do people feel about AGGREGATED-BY-LIR ? Stays in line with the current ones and describes the purpose. Grtx Marco
On 10.9.10 9:44, Marco Hogewoning wrote:
How do people feel about AGGREGATED-BY-LIR ? Stays in line with the current ones and describes the purpose.
+1 /jan
password: D0llemin@ Met vriendelijke groet, ir. A.W. (Andries) Hettema KPN IP-Office kpn-ip-office@kpn.com +31 70 45 13398
Question 1: Why was chosen for "SUB-ASSIGNED PA" and not for "SUB-ALLOCATED PA" or even "LIR-PARTITIONED PA", [...]
[...]
One is to aggregate many individual customers into an assignment block.
It's a rather bikeshedding issue, but maybe pick AGGREGATED PA? LIR-PARTITIONED PA would also be easily understandable, but is a mouthful. :)
I was about to come with the same suggestion. As said, the current one basically is just a placeholder as we needed something in the revision 1 document.
'AGGREGATED XX' is pretty much unique and clearly describes the whole purpose.
How do people feel about AGGREGATED-BY-LIR ? Stays in line with the current ones and describes the purpose.
I like it:) With kind regards, ir. A.W. (Andries) Hettema KPN IP-Office kpn-ip-office@kpn.com +31 70 45 13398
On Fri, Sep 10, 2010 at 09:44:18AM +0200, Marco Hogewoning wrote:
How do people feel about AGGREGATED-BY-LIR ? Stays in line with the current ones and describes the purpose.
I don't really appreciate the "BY-LIR" thing as there is no requirement (that I know of) for the object to be maintained by a LIR. Section 4.0 of the draft confirms this stating that such a block can be a one level more specific of an ASSIGNED inet6num. The main idea of the draft is that assignation details are maintained out of the RIPE database. I would favor things like: - ASSIGNED-EXTERNAL - ASSIGNED-AGGREGATED - AGGREGATED-BY-ORG But none of them is really good. Is there really a need to have a new status for this kind of assignments? I fail to see any reason why ASSIGNED couldn't be used, all the semantics being carried by the assignment-size attribute. Cheers, -- Bertrand Yvain http://www.IELO.net/
On Sep 10, 2010, at 11:42 AM, Bertrand Yvain wrote:
On Fri, Sep 10, 2010 at 09:44:18AM +0200, Marco Hogewoning wrote:
How do people feel about AGGREGATED-BY-LIR ? Stays in line with the current ones and describes the purpose.
I don't really appreciate the "BY-LIR" thing as there is no requirement (that I know of) for the object to be maintained by a LIR. Section 4.0 of the draft confirms this stating that such a block can be a one level more specific of an ASSIGNED inet6num.
The main idea of the draft is that assignation details are maintained out of the RIPE database.
I would favor things like:
- ASSIGNED-EXTERNAL - ASSIGNED-AGGREGATED - AGGREGATED-BY-ORG
But none of them is really good.
Regarding the LIR part, as you can't make assignments from a PI block it will always be PA and therefor LIR (or SUB-ALLOCATED). Marco
+1 // Andreas Andreas Larsen AS12552 IP-Only Telecommunication AB| Postadress: 753 81 UPPSALA | Besöksadress: S:t Persgatan 6, Uppsala | Telefon: +46 (0)18 843 10 00 | Direkt: +46 (0)18 843 10 56 www.ip-only.se -----Ursprungligt meddelande----- Från: ipv6-wg-admin@ripe.net [mailto:ipv6-wg-admin@ripe.net] För Marco Hogewoning Skickat: den 10 september 2010 09:44 Till: ipv6-wg Ämne: Re: [ipv6-wg] Re: [address-policy-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments) On Sep 8, 2010, at 10:20 PM, Marco Hogewoning wrote:
On 8 sep 2010, at 15:49, S.P.Zeidler wrote:
Thus wrote Denis Walker (denis@ripe.net):
Marco Hogewoning wrote:
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", [...]
[...]
One is to aggregate many individual customers into an assignment block.
It's a rather bikeshedding issue, but maybe pick AGGREGATED PA? LIR-PARTITIONED PA would also be easily understandable, but is a mouthful. :)
I was about to come with the same suggestion. As said, the current one basically is just a placeholder as we needed something in the revision 1 document.
'AGGREGATED XX' is pretty much unique and clearly describes the whole purpose.
How do people feel about AGGREGATED-BY-LIR ? Stays in line with the current ones and describes the purpose. Grtx Marco
Marco Hogewoning 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 like the response of Denis about this in his mail of 7-9-2010 14:09: "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
I think it would be wise to explicitely mention this in the proposal and new policy text, to ensure that we don't create confusion for both IPRAs and LIRs. With kind regards, ir. A.W. (Andries) Hettema KPN IP-Office kpn-ip-office@kpn.com +31 70 45 13398
participants (8)
-
Andreas Larsen -
Bertrand Yvain -
Denis Walker -
Jan Zorz ＠ go6.si -
kpn-ip-office＠kpn.com -
Marco Hogewoning -
S.P.Zeidler -
Sander Steffann