From nigel at titley.com Tue May 1 20:18:16 2018 From: nigel at titley.com (Nigel Titley) Date: Tue, 1 May 2018 19:18:16 +0100 Subject: [address-policy-wg] WG Chair selection In-Reply-To: <8443b42a2cf5a17177544c9e34b66eb0.squirrel@webmail.prolocation.net> References: <8443b42a2cf5a17177544c9e34b66eb0.squirrel@webmail.prolocation.net> Message-ID: <581553f7-8087-ba2f-f3c7-14fd899bc189@titley.com> I have to say I'd agree with Paul +1 for Erik On 28/04/18 17:12, Paul Hoogsteder wrote: > Hello AP-WG, > > I don't think I've seen any support for either candidate for the position > of WG chair on the list yet. I think Erik Bais is more than qualified for > such a position, he's been active in the RIPE community and this working > group for years and has made many valuable contributions. > > +many for Erik! > > Best regards, > > Paul Hoogsteder > Meanie AS31019 > Breedband Delft AS34108 > > From stecenkoserj at gmail.com Tue May 1 21:22:08 2018 From: stecenkoserj at gmail.com (Sergey Stecenko) Date: Tue, 01 May 2018 19:22:08 +0000 Subject: [address-policy-wg] WG Chair selection In-Reply-To: <581553f7-8087-ba2f-f3c7-14fd899bc189@titley.com> References: <8443b42a2cf5a17177544c9e34b66eb0.squirrel@webmail.prolocation.net> <581553f7-8087-ba2f-f3c7-14fd899bc189@titley.com> Message-ID: Hi. I think it would be better to discuss about Gert Doering. He is like Angela Merkel, who shows to Europe one way for development and denies others opinions if they doesn't match with his ones. ----------- Kind regards, Sergey Network developer QuickSoft, LLC ??, 1 ??? 2018 ?., 21:18 Nigel Titley : > I have to say I'd agree with Paul > > +1 for Erik > > On 28/04/18 17:12, Paul Hoogsteder wrote: > > Hello AP-WG, > > > > I don't think I've seen any support for either candidate for the position > > of WG chair on the list yet. I think Erik Bais is more than qualified for > > such a position, he's been active in the RIPE community and this working > > group for years and has made many valuable contributions. > > > > +many for Erik! > > > > Best regards, > > > > Paul Hoogsteder > > Meanie AS31019 > > Breedband Delft AS34108 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Tue May 1 22:20:18 2018 From: gert at space.net (Gert Doering) Date: Tue, 1 May 2018 22:20:18 +0200 Subject: [address-policy-wg] WG Chair selection In-Reply-To: References: <8443b42a2cf5a17177544c9e34b66eb0.squirrel@webmail.prolocation.net> <581553f7-8087-ba2f-f3c7-14fd899bc189@titley.com> Message-ID: <20180501202018.GE89741@Space.Net> Hi, On Tue, May 01, 2018 at 07:22:08PM +0000, Sergey Stecenko wrote: > I think it would be better to discuss about Gert Doering. He is like Angela > Merkel, who shows to Europe one way for development and denies others > opinions if they doesn't match with his ones. My term ends next year, not now. So today we're not discussing yet who will replace me. (And whether or not I agree or disagree with folks on the ripe-members list has nothing to do whatsoever with my role as APWG chair) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From wusel+ml at uu.org Tue May 1 22:35:02 2018 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Tue, 1 May 2018 22:35:02 +0200 Subject: [address-policy-wg] WG Chair selection In-Reply-To: References: <8443b42a2cf5a17177544c9e34b66eb0.squirrel@webmail.prolocation.net> <581553f7-8087-ba2f-f3c7-14fd899bc189@titley.com> Message-ID: Am 01.05.2018 um 21:22 schrieb Sergey Stecenko: > I think it would be better to discuss about Gert Doering. He is like Angela Merkel, who shows to Europe one way for development and denies others opinions if they doesn't match with his ones. So, in comparision, you're like Little Donald, bashing other people in totally unrelated contexts? Anyway, JFTR and heading back to topic: +1 for Erik. -kai From sebastian at karotte.org Wed May 2 08:54:09 2018 From: sebastian at karotte.org (Sebastian Wiesinger) Date: Wed, 2 May 2018 08:54:09 +0200 Subject: [address-policy-wg] WG Chair selection In-Reply-To: References: <8443b42a2cf5a17177544c9e34b66eb0.squirrel@webmail.prolocation.net> <581553f7-8087-ba2f-f3c7-14fd899bc189@titley.com> Message-ID: <20180502065409.7ksujbfjtvmfkkgd@danton.fire-world.de> * Sergey Stecenko [2018-05-01 21:23]: > Hi. > > I think it would be better to discuss about Gert Doering. He is like Angela > Merkel, who shows to Europe one way for development and denies others > opinions if they doesn't match with his ones. I find it quite the statistical anomaly that a lot of the people who attack (quite personally) people that do good work *for the community* have more than one address block from 185/8. Maybe we should do some data science on that. Anyway, I ask you to refrain from such attacks once and for all. It makes you look foolish. Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 614 bytes Desc: not available URL: From jordi.palet at consulintel.es Wed May 2 14:25:12 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 02 May 2018 07:25:12 -0500 Subject: [address-policy-wg] inputs on possible policy proposal for IPv6 Message-ID: <1AE708FD-A003-4B55-8D51-EB9F993E44E9@consulintel.es> Hi all, ?As you probably know, ARIN amended some time ago their IPv6 policy proposal in order to make sure that the allocations to LIRs are aligned to the nibble boundary. In the context of another discussion in AfriNIC, Owen DeLong, suggested that we could do something similar. I'm considering submitting a policy proposal in each RIR (RIPE, AfriNIC, LACNIC, APNIC), for that, but I will like to get some inputs before, and "sense" the feeling about that of the participants. Note that in the case of RIPE, we have a big difference with the other RIRs, because all them start with /32, while we updated our policy several years ago (because 6rd deployment), to allocated /29. This means that if we go for this policy, it will be justified to "upgrade" all the /29 allocations to a /28. This is the example that Owen sent to the AfriNIC list: 1. Figure out the number of end sites you expect to serve in your largest aggregation point in 3-5 years. 2. Round that to a nibble boundary (with a 25% minimum free space) (1-12 end sites = 4 bits, 13-192 end sites = 8 bits. 193-3,072 end sites = 12 bits, 3,073-49,152 end sites = 16 bits, 49,153-786,432 = 20 bits, etc.)? Call this E. 3. Figure out the number of aggregation points you expect to have in 3-5 years. Round that up to a nibble boundary with a 25% minimum free space (same as in step 2). Call this A. 4. 48-(A+E) = prefix size. Example: An ISP has 42,000 customers in it?s largest end site. It has 128 end sites. E = 16, A = 8, 48-(16+8) = 48-(24) = 24, this ISP should get a /24. So, would you agree in doing something on this line? Thanks in advance for any inputs! Regards, Jordi ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From phessler at theapt.org Wed May 2 14:45:41 2018 From: phessler at theapt.org (Peter Hessler) Date: Wed, 2 May 2018 14:45:41 +0200 Subject: [address-policy-wg] inputs on possible policy proposal for IPv6 In-Reply-To: <1AE708FD-A003-4B55-8D51-EB9F993E44E9@consulintel.es> References: <1AE708FD-A003-4B55-8D51-EB9F993E44E9@consulintel.es> Message-ID: <20180502124541.GA62396@gir.theapt.org> On 2018 May 02 (Wed) at 07:25:12 -0500 (-0500), JORDI PALET MARTINEZ via address-policy-wg wrote: :Hi all, : :?As you probably know, ARIN amended some time ago their IPv6 policy proposal in order to make sure that the allocations to LIRs are aligned to the nibble boundary. : :In the context of another discussion in AfriNIC, Owen DeLong, suggested that we could do something similar. : :I'm considering submitting a policy proposal in each RIR (RIPE, AfriNIC, LACNIC, APNIC), for that, but I will like to get some inputs before, and "sense" the feeling about that of the participants. : :Note that in the case of RIPE, we have a big difference with the other RIRs, because all them start with /32, while we updated our policy several years ago (because 6rd deployment), to allocated /29. This means that if we go for this policy, it will be justified to "upgrade" all the /29 allocations to a /28. : Using this justification, would that also grow all IPv6 PI /48s to a /44, or only those that are not already at a nibble boundary? :This is the example that Owen sent to the AfriNIC list: : :1. Figure out the number of end sites you expect to serve in your largest aggregation point : in 3-5 years. :2. Round that to a nibble boundary (with a 25% minimum free space) (1-12 end sites = 4 bits, : 13-192 end sites = 8 bits. 193-3,072 end sites = 12 bits, 3,073-49,152 end sites = 16 bits, : 49,153-786,432 = 20 bits, etc.)? Call this E. :3. Figure out the number of aggregation points you expect to have in 3-5 years. Round that up : to a nibble boundary with a 25% minimum free space (same as in step 2). Call this A. :4. 48-(A+E) = prefix size. : : Example: An ISP has 42,000 customers in it?s largest end site. It has 128 end sites. : E = 16, A = 8, 48-(16+8) = 48-(24) = 24, this ISP should get a /24. : :So, would you agree in doing something on this line? : :Thanks in advance for any inputs! : :Regards, :Jordi : : : : : :********************************************** :IPv4 is over :Are you ready for the new Internet ? :http://www.consulintel.es :The IPv6 Company -- Broad-mindedness, n.: The result of flattening high-mindedness out. From jordi.palet at consulintel.es Wed May 2 15:23:00 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 02 May 2018 08:23:00 -0500 Subject: [address-policy-wg] inputs on possible policy proposal for IPv6 In-Reply-To: <20180502124541.GA62396@gir.theapt.org> References: <1AE708FD-A003-4B55-8D51-EB9F993E44E9@consulintel.es> <20180502124541.GA62396@gir.theapt.org> Message-ID: <804E75CE-2C7D-491C-B6B8-D4B6065A9F67@consulintel.es> Hi Peter, /48 is already in a nibble boundary, so no chance :-) Despite that, initially I'm considering only the policy for IPv6 PA (LIRs/ISPs). If the inputs provide a view that this should be the same for IPv6 PI, I've no issue in do that one as well, so in that case if you have previously justified, for example, a /47, you should automatically be able to get the /44. However, if we believe that both should be proposed (nibble boundary for IPv6 PA and nibble boundary for IPv6 PI) I think it will be better decoupled in separate policy proposals, to facilitate the discussion and possible consensus, and again no problem from my side to work on both. Regards, Jordi ?-----Mensaje original----- De: address-policy-wg en nombre de Peter Hessler Fecha: mi?rcoles, 2 de mayo de 2018, 7:45 Para: Asunto: Re: [address-policy-wg] inputs on possible policy proposal for IPv6 On 2018 May 02 (Wed) at 07:25:12 -0500 (-0500), JORDI PALET MARTINEZ via address-policy-wg wrote: :Hi all, : :?As you probably know, ARIN amended some time ago their IPv6 policy proposal in order to make sure that the allocations to LIRs are aligned to the nibble boundary. : :In the context of another discussion in AfriNIC, Owen DeLong, suggested that we could do something similar. : :I'm considering submitting a policy proposal in each RIR (RIPE, AfriNIC, LACNIC, APNIC), for that, but I will like to get some inputs before, and "sense" the feeling about that of the participants. : :Note that in the case of RIPE, we have a big difference with the other RIRs, because all them start with /32, while we updated our policy several years ago (because 6rd deployment), to allocated /29. This means that if we go for this policy, it will be justified to "upgrade" all the /29 allocations to a /28. : Using this justification, would that also grow all IPv6 PI /48s to a /44, or only those that are not already at a nibble boundary? :This is the example that Owen sent to the AfriNIC list: : :1. Figure out the number of end sites you expect to serve in your largest aggregation point : in 3-5 years. :2. Round that to a nibble boundary (with a 25% minimum free space) (1-12 end sites = 4 bits, : 13-192 end sites = 8 bits. 193-3,072 end sites = 12 bits, 3,073-49,152 end sites = 16 bits, : 49,153-786,432 = 20 bits, etc.)? Call this E. :3. Figure out the number of aggregation points you expect to have in 3-5 years. Round that up : to a nibble boundary with a 25% minimum free space (same as in step 2). Call this A. :4. 48-(A+E) = prefix size. : : Example: An ISP has 42,000 customers in it?s largest end site. It has 128 end sites. : E = 16, A = 8, 48-(16+8) = 48-(24) = 24, this ISP should get a /24. : :So, would you agree in doing something on this line? : :Thanks in advance for any inputs! : :Regards, :Jordi : : : : : :********************************************** :IPv4 is over :Are you ready for the new Internet ? :http://www.consulintel.es :The IPv6 Company -- Broad-mindedness, n.: The result of flattening high-mindedness out. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From gert at space.net Wed May 2 16:35:15 2018 From: gert at space.net (Gert Doering) Date: Wed, 2 May 2018 16:35:15 +0200 Subject: [address-policy-wg] inputs on possible policy proposal for IPv6 In-Reply-To: <1AE708FD-A003-4B55-8D51-EB9F993E44E9@consulintel.es> References: <1AE708FD-A003-4B55-8D51-EB9F993E44E9@consulintel.es> Message-ID: <20180502143514.GA89741@Space.Net> Hi, On Wed, May 02, 2018 at 07:25:12AM -0500, JORDI PALET MARTINEZ via address-policy-wg wrote: > ???As you probably know, ARIN amended some time ago their IPv6 policy proposal in order to make sure that the allocations to LIRs are aligned to the nibble boundary. Speaking as a long-time IPv6 user, I see no real benefit in this. Yes, a /29 means I have to set up 8 reverse DNS zones, instead of one. Bummer. And my IP management tool might need to learn about non-magic bit numbers (but it will need to understand that anyway if I do reasonably-sized internal suballocations, like "a /34 for a region" and not "a /36 because the tool cannot do /34s"). "Just because ARIN does it" is also not a good reason to follow suit - like, "lots of people going for /36 allocations, because /32 is too big and, priced-by-size, too expensive"... (But this is strictly my *personal* opinion. If there is sufficient support in the WG, I'll shepherd a corresponding proposal, of course) Gert Doering -- long time IPv6 allocation holder -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From jordi.palet at consulintel.es Wed May 2 17:04:05 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 02 May 2018 10:04:05 -0500 Subject: [address-policy-wg] inputs on possible policy proposal for IPv6 In-Reply-To: <20180502143514.GA89741@Space.Net> References: <1AE708FD-A003-4B55-8D51-EB9F993E44E9@consulintel.es> <20180502143514.GA89741@Space.Net> Message-ID: <24A0C3C5-19A6-4630-BD94-094128521008@consulintel.es> Of course, in case it was not clear, I didn't want to mean "because ARIN did that, we should do the same as well". It was just a matter of providing context. Regards, Jordi ?-----Mensaje original----- De: address-policy-wg en nombre de Gert Doering Fecha: mi?rcoles, 2 de mayo de 2018, 9:35 Para: JORDI PALET MARTINEZ CC: RIPE Address Policy WG List Asunto: Re: [address-policy-wg] inputs on possible policy proposal for IPv6 Hi, On Wed, May 02, 2018 at 07:25:12AM -0500, JORDI PALET MARTINEZ via address-policy-wg wrote: > ???As you probably know, ARIN amended some time ago their IPv6 policy proposal in order to make sure that the allocations to LIRs are aligned to the nibble boundary. Speaking as a long-time IPv6 user, I see no real benefit in this. Yes, a /29 means I have to set up 8 reverse DNS zones, instead of one. Bummer. And my IP management tool might need to learn about non-magic bit numbers (but it will need to understand that anyway if I do reasonably-sized internal suballocations, like "a /34 for a region" and not "a /36 because the tool cannot do /34s"). "Just because ARIN does it" is also not a good reason to follow suit - like, "lots of people going for /36 allocations, because /32 is too big and, priced-by-size, too expensive"... (But this is strictly my *personal* opinion. If there is sufficient support in the WG, I'll shepherd a corresponding proposal, of course) Gert Doering -- long time IPv6 allocation holder -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From mschmidt at ripe.net Thu May 3 17:08:25 2018 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 03 May 2018 17:08:25 +0200 Subject: [address-policy-wg] 2018-01 Review Phase (Organisation-LIR Clarification in IPv6 Policy) Message-ID: Dear colleagues, Policy proposal 2018-01, "Organisation-LIR Clarification in IPv6 Policy" is now in the Review Phase. This proposal aims to clarify the wording used in ripe-699 regarding terms such as "organisation" and "LIR". The proposal has been updated following the last round of discussion and is now at version v2.0. Some of the differences from version v1.0 include: - Clarifies when the subsequent allocation policy applies - Fixing some typos The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community?s discussion. You can find the full proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2018-01 And the draft documents at: https://www.ripe.net/participate/policies/proposals/2018-01/draft As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussing the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. At the end of the Review Phase, the WG Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. We encourage you to read the proposal, impact analysis and draft document and send any comments to before 1 June 2018. Kind regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From Ian.Dickinson at tfmnetworks.com Fri May 4 10:42:43 2018 From: Ian.Dickinson at tfmnetworks.com (Ian Dickinson) Date: Fri, 4 May 2018 08:42:43 +0000 Subject: [address-policy-wg] 2018-01 Review Phase (Organisation-LIR Clarification in IPv6 Policy) In-Reply-To: References: Message-ID: There are a number of occurrences of "an LIR" (and also "An LIR") throughout the document that should be changed to "a LIR". Presumably only s/Organisation/LIR/ was done. Other than this grammar nit, I am happy the text matches the goal and I support it. Ian -----Original Message----- From: address-policy-wg On Behalf Of Marco Schmidt Sent: 03 May 2018 16:08 To: address-policy-wg at ripe.net Subject: [address-policy-wg] 2018-01 Review Phase (Organisation-LIR Clarification in IPv6 Policy) Dear colleagues, Policy proposal 2018-01, "Organisation-LIR Clarification in IPv6 Policy" is now in the Review Phase. This proposal aims to clarify the wording used in ripe-699 regarding terms such as "organisation" and "LIR". The proposal has been updated following the last round of discussion and is now at version v2.0. Some of the differences from version v1.0 include: - Clarifies when the subsequent allocation policy applies - Fixing some typos The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community?s discussion. You can find the full proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2018-01 And the draft documents at: https://www.ripe.net/participate/policies/proposals/2018-01/draft As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussing the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. At the end of the Review Phase, the WG Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. We encourage you to read the proposal, impact analysis and draft document and send any comments to before 1 June 2018. Kind regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more visit the Mimecast website. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian at karotte.org Fri May 4 13:52:10 2018 From: sebastian at karotte.org (Sebastian Wiesinger) Date: Fri, 4 May 2018 13:52:10 +0200 Subject: [address-policy-wg] inputs on possible policy proposal for IPv6 In-Reply-To: <1AE708FD-A003-4B55-8D51-EB9F993E44E9@consulintel.es> References: <1AE708FD-A003-4B55-8D51-EB9F993E44E9@consulintel.es> Message-ID: <20180504115210.r6cyw2clbnn4qfdp@danton.fire-world.de> * JORDI PALET MARTINEZ via address-policy-wg [2018-05-02 14:26]: > Note that in the case of RIPE, we have a big difference with the > other RIRs, because all them start with /32, while we updated our > policy several years ago (because 6rd deployment), to allocated /29. > This means that if we go for this policy, it will be justified to > "upgrade" all the /29 allocations to a /28. Hi, I'm not sure I see the big benefit of upgrading to a /28 but on a purely technical standpoint, "upgrading" is not possible in most cases because RIPE NCC did not reserve a complete /28 for every LIR. So you would end up with two /29 or you'd have to renumber your /29 to a new /28. Both options don't sound appealing to me. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 614 bytes Desc: not available URL: From jordi.palet at consulintel.es Fri May 4 15:50:25 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 04 May 2018 08:50:25 -0500 Subject: [address-policy-wg] inputs on possible policy proposal for IPv6 In-Reply-To: <20180504115210.r6cyw2clbnn4qfdp@danton.fire-world.de> References: <1AE708FD-A003-4B55-8D51-EB9F993E44E9@consulintel.es> <20180504115210.r6cyw2clbnn4qfdp@danton.fire-world.de> Message-ID: Hi Sebastian, As said, is just an idea, and I'm not yet nailing down all the details, but I don't think, in general, and ISP that has advanced his deployment, will renumber ... so of course I will not suggest that as mandatory, only an option in case some want to do (there are a few ISPs that got their /29 and didn't deployed IPv6 at all, so it make sense for them). On the other side, it will be nice, in order to understand how much is the impact of this, if the NCC can provide a summary of how many of the actual RIRs that have a non-nibble boundary allocation, will not be able to get it upgraded to the nibble-boundary one because the precedent space has been already allocated to someone else, etc. Regards, Jordi ?-----Mensaje original----- De: address-policy-wg en nombre de Sebastian Wiesinger Fecha: viernes, 4 de mayo de 2018, 6:52 Para: Asunto: Re: [address-policy-wg] inputs on possible policy proposal for IPv6 * JORDI PALET MARTINEZ via address-policy-wg [2018-05-02 14:26]: > Note that in the case of RIPE, we have a big difference with the > other RIRs, because all them start with /32, while we updated our > policy several years ago (because 6rd deployment), to allocated /29. > This means that if we go for this policy, it will be justified to > "upgrade" all the /29 allocations to a /28. Hi, I'm not sure I see the big benefit of upgrading to a /28 but on a purely technical standpoint, "upgrading" is not possible in most cases because RIPE NCC did not reserve a complete /28 for every LIR. So you would end up with two /29 or you'd have to renumber your /29 to a new /28. Both options don't sound appealing to me. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From scottleibrand at gmail.com Fri May 4 17:01:22 2018 From: scottleibrand at gmail.com (Scott Leibrand) Date: Fri, 4 May 2018 08:01:22 -0700 Subject: [address-policy-wg] 2018-01 Review Phase (Organisation-LIR Clarification in IPv6 Policy) In-Reply-To: References: Message-ID: If LIR is pronounced ?Elle-Eye-Are? (which is how I pronounce it) then ?an LIR? is correct. It would only be ?a LIR? if you pronounce it ?Lear?. http://blog.apastyle.org/apastyle/2012/04/using-a-or-an-with-acronyms-and-abbreviations.html Scott > On May 4, 2018, at 1:42 AM, Ian Dickinson wrote: > > There are a number of occurrences of "an LIR" (and also "An LIR") throughout the document that should be changed to "a LIR". > Presumably only s/Organisation/LIR/ was done. > > Other than this grammar nit, I am happy the text matches the goal and I support it. > > Ian > > -----Original Message----- > From: address-policy-wg On Behalf Of Marco Schmidt > Sent: 03 May 2018 16:08 > To: address-policy-wg at ripe.net > Subject: [address-policy-wg] 2018-01 Review Phase (Organisation-LIR Clarification in IPv6 Policy) > > Dear colleagues, > > Policy proposal 2018-01, "Organisation-LIR Clarification in IPv6 Policy" is now in the Review Phase. > > This proposal aims to clarify the wording used in ripe-699 regarding terms such as "organisation" and "LIR". > > The proposal has been updated following the last round of discussion and is now at version v2.0. Some of the differences from version v1.0 include: > - Clarifies when the subsequent allocation policy applies > - Fixing some typos > > The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community?s discussion. You can find the full proposal and impact analysis at: > https://www.ripe.net/participate/policies/proposals/2018-01 > > And the draft documents at: > https://www.ripe.net/participate/policies/proposals/2018-01/draft > > As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussing the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. > > At the end of the Review Phase, the WG Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. > > We encourage you to read the proposal, impact analysis and draft document and send any comments to before 1 June 2018. > > Kind regards, > > Marco Schmidt > Policy Officer > RIPE NCC > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > > > Disclaimer > > This email is private and may be confidential and is intended for the recipient only. If misdirected please notify us by telephone and return and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this email or any information within it. We use reasonable endeavours to virus scan all emails leaving our organisation but no warranty is given that this email and any attachments are virus free. You should undertake your own virus checking. The right to monitor email communication through our networks is reserved by us. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Fri May 4 17:05:20 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 04 May 2018 10:05:20 -0500 Subject: [address-policy-wg] 2018-01 Review Phase (Organisation-LIR Clarification in IPv6 Policy) In-Reply-To: References: Message-ID: <91292D9C-DC42-4A39-A53C-8C32DB5570F7@consulintel.es> Hi all, This is a grammar details that doesn?t affect the policy proposal content. I?m fine either way, but of course, I?m not native English, and the way it is being used in the document right now, was the suggested NCC format. So, I will say I?m happy if they choose one way or another, for consistence with the rest of the policies in the region. Regards, Jordi De: address-policy-wg en nombre de Scott Leibrand Fecha: viernes, 4 de mayo de 2018, 10:01 Para: Ian Dickinson CC: "address-policy-wg at ripe.net" Asunto: Re: [address-policy-wg] 2018-01 Review Phase (Organisation-LIR Clarification in IPv6 Policy) If LIR is pronounced ?Elle-Eye-Are? (which is how I pronounce it) then ?an LIR? is correct. It would only be ?a LIR? if you pronounce it ?Lear?. http://blog.apastyle.org/apastyle/2012/04/using-a-or-an-with-acronyms-and-abbreviations.html Scott On May 4, 2018, at 1:42 AM, Ian Dickinson wrote: There are a number of occurrences of "an LIR" (and also "An LIR") throughout the document that should be changed to "a LIR". Presumably only s/Organisation/LIR/ was done. Other than this grammar nit, I am happy the text matches the goal and I support it. Ian -----Original Message----- From: address-policy-wg On Behalf Of Marco Schmidt Sent: 03 May 2018 16:08 To: address-policy-wg at ripe.net Subject: [address-policy-wg] 2018-01 Review Phase (Organisation-LIR Clarification in IPv6 Policy) Dear colleagues, Policy proposal 2018-01, "Organisation-LIR Clarification in IPv6 Policy" is now in the Review Phase. This proposal aims to clarify the wording used in ripe-699 regarding terms such as "organisation" and "LIR". The proposal has been updated following the last round of discussion and is now at version v2.0. Some of the differences from version v1.0 include: - Clarifies when the subsequent allocation policy applies - Fixing some typos The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community?s discussion. You can find the full proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2018-01 And the draft documents at: https://www.ripe.net/participate/policies/proposals/2018-01/draft As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussing the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. At the end of the Review Phase, the WG Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. We encourage you to read the proposal, impact analysis and draft document and send any comments to before 1 June 2018. Kind regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum Disclaimer This email is private and may be confidential and is intended for the recipient only. If misdirected please notify us by telephone and return and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this email or any information within it. We use reasonable endeavours to virus scan all emails leaving our organisation but no warranty is given that this email and any attachments are virus free. You should undertake your own virus checking. The right to monitor email communication through our networks is reserved by us. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From noc at ntx.ru Sat May 5 14:41:12 2018 From: noc at ntx.ru (NOC Hostmaster) Date: Sat, 5 May 2018 15:41:12 +0300 Subject: [address-policy-wg] 2018-01 Review Phase (Organisation-LIR Clarification in IPv6 Policy) In-Reply-To: <91292D9C-DC42-4A39-A53C-8C32DB5570F7@consulintel.es> References: <91292D9C-DC42-4A39-A53C-8C32DB5570F7@consulintel.es> Message-ID: <9e9c6979-c586-b79c-11cc-6c802143f5d2@ntx.ru> I agree with Jordi, Even simplest changes takes too long at RIPE NCC (and other RIRs). Nikolay On 04.05.2018 18:05, JORDI PALET MARTINEZ via address-policy-wg wrote: > Hi all, > > ? > > This is a grammar details that doesn?t affect the policy proposal > content. I?m fine either way, but of course, I?m not native English, and > the way it is being used in the document right now, was the suggested > NCC format. > > ? > > So, I will say I?m happy if they choose one way or another, for > consistence with the rest of the policies in the region. > > > Regards, > > Jordi > > From sean.stuart at gmail.com Sat May 5 18:44:04 2018 From: sean.stuart at gmail.com (Sean Stuart) Date: Sat, 5 May 2018 12:44:04 -0400 Subject: [address-policy-wg] WG chair change In-Reply-To: References: <20180309101630.GU89741@Space.Net> Message-ID: <495DDE86-08B2-4319-A22E-E2F248FA1054@gmail.com> Hi AP-WG members, In the interest of easing consensus in the address policy community, I would like to withdraw my candidacy for WG chair. I strongly encourage everyone to support Erik as the future WG chair based on the significant work he has done for the community over the last several years. I have complete confidence in his stewardship of the group in the future. Thank you. > On Mar 12, 2018, at 9:29 AM, Sean Stuart wrote: > > Hi Gert, Sander & AP-WG members, > > Thank you for the email, and I am volunteering to serve the working group. > > My name is Sean Stuart, and I have been working with enterprise and service provider networks for the last 20 years. > My current role involves Internet peering, DNS root server placement, and IP address management. Wearing my IP management hat, I operate five LIR's under three RIR's, and follow the policy development process in all three regions. > I am very familiar with the policy development process in RIPE, and appreciate the process and the work required to keep the process on track. I also bring a neutral perspective to the role, as neither my employer nor myself have any specific policy requests expected in the near future. > My goal is to ensure that the working group is able to continue to develop policies that make sense to the organizations in the RIPE region for the next several years. I am familiar with the workload required, as well as the role of the WG chair in keeping discussions on track and civil when required. > > I hope to be able to serve the community as a WG chair. > > Thank you, > Sean Stuart > > > >> On Fri, Mar 9, 2018 at 5:16 AM, Gert Doering wrote: >> Dear AP WG, >> >> as announced, my co-chairs of amazingly many years, Sander Steffann, will >> be stepping down as a WG chair at the next RIPE meeting. >> >> Our WG chair selection policy is described here: >> >> https://www.ripe.net/participate/ripe/wg/ap >> https://www.ripe.net/participate/ripe/wg/ap/address-policy-wg-chair-selection-process >> >> according to this, we'll spend a few minutes at the next APWG session >> in Marseilles to select a new co-chair. >> >> To avoid lengthy rounds of introduction at the meeting, I want to ask >> for volunteers here on the list - please step forward if you want to >> take up this work, and introduce yourself on why you think you're a >> good candidate and what your plans for the WG are for the next two years >> (or longer). >> >> A short recap of the WG chairs duties: >> >> - chair the APWG session at the RIPE meetings >> (so generally it is expected that both co-chairs can attend most >> RIPE meetings and feel halfway confident talking on stage and >> moderate a discussion) >> >> - read - and if necessary, moderate - the APWG mailing list >> (thus, fluency in written English is necessary, and while discussions >> are going on, some amount time spent at least every few days) >> >> - help policy proposers bring their policy proposal through the PDP >> (answering questions, helping with the wording of proposed text, >> spending some time discussing 'next steps' for a proposal) >> >> - judge consensus at the end of discussion and review phases according >> to our policy development process >> (usually done by both co-chairs together, unless a conflict of interest >> appears) >> >> - help shape the format of RIPE meetings together with all the other >> WG chairs and the RIPE PC - by mailing list and by attending the >> "WG chair lunch" on RIPE meeting Thursdays >> >> - see also: https://www.ripe.net/publications/docs/ripe-692 >> >> A definite plus for an APWG chair is "operational experience with these >> pesky numbers" - either by operating the address management side (LIR) >> of an Internet Service Provider or Enterprise network, or by being an >> address broker, etc. >> >> >> Sander and I have spoken to a few of you who would make good chairs already >> - but ultimately, it's up the working group to decide. So even if you have >> spoken to us privately before, please speak up now. >> >> So, come forward, dear candidates and make yourself known! :-) >> >> Gert Doering >> -- APWG chair >> -- >> have you enabled IPv6 on something today...? >> >> SpaceNet AG Vorstand: Sebastian v. Bomhard >> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann >> D-80807 Muenchen HRB: 136055 (AG Muenchen) >> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > > > -- > Thank you, > Sean Stuart > sean.stuart at gmail.com > 571-969-5707 cell -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Sat May 5 20:51:12 2018 From: sander at steffann.nl (Sander Steffann) Date: Sat, 5 May 2018 20:51:12 +0200 Subject: [address-policy-wg] WG chair change In-Reply-To: <495DDE86-08B2-4319-A22E-E2F248FA1054@gmail.com> References: <20180309101630.GU89741@Space.Net> <495DDE86-08B2-4319-A22E-E2F248FA1054@gmail.com> Message-ID: Hi Sean, > In the interest of easing consensus in the address policy community, I would like to withdraw my candidacy for WG chair. I strongly encourage everyone to support Erik as the future WG chair based on the significant work he has done for the community over the last several years. I have complete confidence in his stewardship of the group in the future. Thank you. I understand. Thank you for volunteering in the first place! I know you as a level-headed person and I'm convinced that you are more than capable of being a good working group chair. Please keep volunteering for other chair positions in the future :) Cheers, Sander From wilhelm at boeddinghaus.de Sun May 6 13:14:30 2018 From: wilhelm at boeddinghaus.de (Wilhelm Boeddinghaus) Date: Sun, 6 May 2018 13:14:30 +0200 Subject: [address-policy-wg] WG Chair selection In-Reply-To: References: <8443b42a2cf5a17177544c9e34b66eb0.squirrel@webmail.prolocation.net> <581553f7-8087-ba2f-f3c7-14fd899bc189@titley.com> Message-ID: <3857d21e-9574-234d-7b6d-884d45c144ef@boeddinghaus.de> Hi Sergey, I know we do not discuss about Gert this time, but I am looking forward to next year when you step forward to get appointed as a working group chair for this group. Then you can show some neutrality in your work for the community. Go ahead. Best, Wilhelm Am 01.05.2018 um 21:22 schrieb Sergey Stecenko: > Hi. > > I think it would be better to discuss about?Gert Doering. He is like > Angela Merkel, who shows to Europe one way for development and denies? > others opinions if they doesn't match with his ones. > > ----------- > Kind regards, > Sergey > Network developer > QuickSoft, LLC > > ??, 1 ??? 2018 ?., 21:18 Nigel Titley >: > > I have to say I'd agree with Paul > > +1 for Erik > > On 28/04/18 17:12, Paul Hoogsteder wrote: > > Hello AP-WG, > > > > I don't think I've seen any support for either candidate for the > position > > of WG chair on the list yet. I think Erik Bais is more than > qualified for > > such a position, he's been active in the RIPE community and this > working > > group for years and has made many valuable contributions. > > > > +many for Erik! > > > > Best regards, > > > > Paul Hoogsteder > > Meanie AS31019 > > Breedband Delft AS34108 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at rfc1035.com Sun May 6 15:04:49 2018 From: jim at rfc1035.com (Jim Reid) Date: Sun, 6 May 2018 14:04:49 +0100 Subject: [address-policy-wg] 2018-01 Review Phase (Organisation-LIR Clarification in IPv6 Policy) In-Reply-To: <9e9c6979-c586-b79c-11cc-6c802143f5d2@ntx.ru> References: <91292D9C-DC42-4A39-A53C-8C32DB5570F7@consulintel.es> <9e9c6979-c586-b79c-11cc-6c802143f5d2@ntx.ru> Message-ID: > On 5 May 2018, at 13:41, NOC Hostmaster wrote: > > Even simplest changes takes too long at RIPE NCC (and other RIRs). ??? If the problem is how the NCC implements some policy, surely we should fix that rather than change the policy? FWIW I'm not expressing an opinion either way on 2018-01. From jim at rfc1035.com Sun May 6 15:05:32 2018 From: jim at rfc1035.com (Jim Reid) Date: Sun, 6 May 2018 14:05:32 +0100 Subject: [address-policy-wg] 2018-01 Review Phase (Organisation-LIR Clarification in IPv6 Policy) In-Reply-To: <9e9c6979-c586-b79c-11cc-6c802143f5d2@ntx.ru> References: <91292D9C-DC42-4A39-A53C-8C32DB5570F7@consulintel.es> <9e9c6979-c586-b79c-11cc-6c802143f5d2@ntx.ru> Message-ID: <877D4108-859C-4E95-A69A-4BBC67926FCF@rfc1035.com> > On 5 May 2018, at 13:41, NOC Hostmaster wrote: > > Even simplest changes takes too long at RIPE NCC (and other RIRs). ??? If the problem is how the NCC implements some policy, surely we should fix that rather than change the policy? FWIW I'm not expressing an opinion either way on 2018-01. From iljitsch at muada.com Sun May 6 21:11:58 2018 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sun, 6 May 2018 21:11:58 +0200 Subject: [address-policy-wg] IP/ASNs for Governments BoF Message-ID: <1580A98E-E254-462E-ACD4-89358B5E19AB@muada.com> Hi all, I'd like to call your attention to a BoF that was added to the schedule last week: IP/ASNs for Governments Iljitsch van Beijnum, Logius, Dutch Ministry of the Interior and Kingdom Relations The purpose of this BoF is to discuss the needs of government and large organisations when it comes to IPv6 address allocations and ASN assignments. We will cover the ways in which RIPE Policies could be changed to better support these large entities that are often comprised of many independent sub-organisations with their own connections to the Internet. Please also note my (relatively) new affiliation. :-) However, I'm using my old email address here to avoid even more spam. The idea behind this BoF is that governments (and some other very large organizations) find it useful to number all their sub-organizations from a single large block, but these sub-organizations connect to the internet independently. We've done this with the Dutch government-wide IPv6 numbering plan, which provides IPv6 addresses to the national government, but also provinces and cities. In Germany there's also a similar IPv6 numbering plan. However, the RIPE policies don't fit this use case very well. We believe it would be useful to start a discussion with the community to see how this is best addressed. There's also some issues surrounding the use of public AS numbers for very large private networks. I haven't been on this list for a number of years, so if all of this has been discussed recently, my apologies. The full BoF proposal is here: https://ripe76.ripe.net/wp-content/uploads/submissions/RIPE-76-IP-ASNs-for-governments-BoF.pdf Iljitsch van Beijnum -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Sun May 6 23:51:22 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sun, 06 May 2018 23:51:22 +0200 Subject: [address-policy-wg] IP/ASNs for Governments BoF In-Reply-To: <1580A98E-E254-462E-ACD4-89358B5E19AB@muada.com> References: <1580A98E-E254-462E-ACD4-89358B5E19AB@muada.com> Message-ID: <68153F07-8801-4CE0-A778-3B06BB60BF55@consulintel.es> Hi Iljitsch, When is this BoF? I?ve worked in policy proposals to solve this problem in several RIRs, so I fail to see what further problem do you find. Anyway, happy to participate and contribute if there is one. Regards, Jordi De: address-policy-wg en nombre de Iljitsch van Beijnum Fecha: domingo, 6 de mayo de 2018, 21:12 Para: Asunto: [address-policy-wg] IP/ASNs for Governments BoF Hi all, I'd like to call your attention to a BoF that was added to the schedule last week: IP/ASNs for Governments Iljitsch van Beijnum, Logius, Dutch Ministry of the Interior and Kingdom Relations The purpose of this BoF is to discuss the needs of government and large organisations when it comes to IPv6 address allocations and ASN assignments. We will cover the ways in which RIPE Policies could be changed to better support these large entities that are often comprised of many independent sub-organisations with their own connections to the Internet. Please also note my (relatively) new affiliation. :-) However, I'm using my old email address here to avoid even more spam. The idea behind this BoF is that governments (and some other very large organizations) find it useful to number all their sub-organizations from a single large block, but these sub-organizations connect to the internet independently. We've done this with the Dutch government-wide IPv6 numbering plan, which provides IPv6 addresses to the national government, but also provinces and cities. In Germany there's also a similar IPv6 numbering plan. However, the RIPE policies don't fit this use case very well. We believe it would be useful to start a discussion with the community to see how this is best addressed. There's also some issues surrounding the use of public AS numbers for very large private networks. I haven't been on this list for a number of years, so if all of this has been discussed recently, my apologies. The full BoF proposal is here: https://ripe76.ripe.net/wp-content/uploads/submissions/RIPE-76-IP-ASNs-for-governments-BoF.pdf Iljitsch van Beijnum ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebais at a2b-internet.com Mon May 7 11:17:27 2018 From: ebais at a2b-internet.com (Erik Bais) Date: Mon, 7 May 2018 09:17:27 +0000 Subject: [address-policy-wg] WG chair change In-Reply-To: <495DDE86-08B2-4319-A22E-E2F248FA1054@gmail.com> References: <20180309101630.GU89741@Space.Net> <495DDE86-08B2-4319-A22E-E2F248FA1054@gmail.com> Message-ID: Hi Sean, Thank you for your support. Looking forward to see you in Marseille. Regards, Erik Bais [signature_1256050601] [signature_1459106859] Erik Bais | A2B Internet | +31 85 902 0410 ( Office ) | ebais at a2b-internet.com | From: address-policy-wg on behalf of Sean Stuart Date: Saturday 5 May 2018 at 18:44 To: "address-policy-wg at ripe.net" Subject: Re: [address-policy-wg] WG chair change Hi AP-WG members, In the interest of easing consensus in the address policy community, I would like to withdraw my candidacy for WG chair. I strongly encourage everyone to support Erik as the future WG chair based on the significant work he has done for the community over the last several years. I have complete confidence in his stewardship of the group in the future. Thank you. On Mar 12, 2018, at 9:29 AM, Sean Stuart > wrote: Hi Gert, Sander & AP-WG members, Thank you for the email, and I am volunteering to serve the working group. My name is Sean Stuart, and I have been working with enterprise and service provider networks for the last 20 years. My current role involves Internet peering, DNS root server placement, and IP address management. Wearing my IP management hat, I operate five LIR's under three RIR's, and follow the policy development process in all three regions. I am very familiar with the policy development process in RIPE, and appreciate the process and the work required to keep the process on track. I also bring a neutral perspective to the role, as neither my employer nor myself have any specific policy requests expected in the near future. My goal is to ensure that the working group is able to continue to develop policies that make sense to the organizations in the RIPE region for the next several years. I am familiar with the workload required, as well as the role of the WG chair in keeping discussions on track and civil when required. I hope to be able to serve the community as a WG chair. Thank you, Sean Stuart On Fri, Mar 9, 2018 at 5:16 AM, Gert Doering > wrote: Dear AP WG, as announced, my co-chairs of amazingly many years, Sander Steffann, will be stepping down as a WG chair at the next RIPE meeting. Our WG chair selection policy is described here: https://www.ripe.net/participate/ripe/wg/ap https://www.ripe.net/participate/ripe/wg/ap/address-policy-wg-chair-selection-process according to this, we'll spend a few minutes at the next APWG session in Marseilles to select a new co-chair. To avoid lengthy rounds of introduction at the meeting, I want to ask for volunteers here on the list - please step forward if you want to take up this work, and introduce yourself on why you think you're a good candidate and what your plans for the WG are for the next two years (or longer). A short recap of the WG chairs duties: - chair the APWG session at the RIPE meetings (so generally it is expected that both co-chairs can attend most RIPE meetings and feel halfway confident talking on stage and moderate a discussion) - read - and if necessary, moderate - the APWG mailing list (thus, fluency in written English is necessary, and while discussions are going on, some amount time spent at least every few days) - help policy proposers bring their policy proposal through the PDP (answering questions, helping with the wording of proposed text, spending some time discussing 'next steps' for a proposal) - judge consensus at the end of discussion and review phases according to our policy development process (usually done by both co-chairs together, unless a conflict of interest appears) - help shape the format of RIPE meetings together with all the other WG chairs and the RIPE PC - by mailing list and by attending the "WG chair lunch" on RIPE meeting Thursdays - see also: https://www.ripe.net/publications/docs/ripe-692 A definite plus for an APWG chair is "operational experience with these pesky numbers" - either by operating the address management side (LIR) of an Internet Service Provider or Enterprise network, or by being an address broker, etc. Sander and I have spoken to a few of you who would make good chairs already - but ultimately, it's up the working group to decide. So even if you have spoken to us privately before, please speak up now. So, come forward, dear candidates and make yourself known! :-) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -- Thank you, Sean Stuart sean.stuart at gmail.com 571-969-5707 cell -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1350 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 1335 bytes Desc: image002.png URL: From iljitsch at muada.com Mon May 7 12:49:00 2018 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 7 May 2018 12:49:00 +0200 Subject: [address-policy-wg] IP/ASNs for Governments BoF In-Reply-To: <68153F07-8801-4CE0-A778-3B06BB60BF55@consulintel.es> References: <1580A98E-E254-462E-ACD4-89358B5E19AB@muada.com> <68153F07-8801-4CE0-A778-3B06BB60BF55@consulintel.es> Message-ID: <9CFC3754-739C-49F8-9834-1889E740B031@muada.com> Hi Jordi, On 6 May 2018, at 23:51, JORDI PALET MARTINEZ via address-policy-wg wrote: > When is this BoF? Thursday, last session before the RIPE-dinner. > I?ve worked in policy proposals to solve this problem in several RIRs, so I fail to see what further problem do you find. What are those policy proposals? We encountered all of this about two years ago, perhaps things have changed since then? Iljitsch From jkennedy at libertyglobal.com Sat May 12 17:20:27 2018 From: jkennedy at libertyglobal.com (Kennedy, James) Date: Sat, 12 May 2018 15:20:27 +0000 Subject: [address-policy-wg] FW: WG chair change In-Reply-To: References: <20180309101630.GU89741@Space.Net> <615EAE6B-2D5D-4657-A6BA-EAAB34E62093@a2b-internet.com> Message-ID: <13E63C78A6256E4A857726374FBF926E183CEE04@NLAMSPEXMB022.upcit.ds.upc.biz> + 1 for Erik Through his many years of positive contribution to this wg, I trust Erik has the necessary AP knowledge and PDP experience to be a very good chair. Hope all planning to travel make it to Marseille. See you there :) Regards, James -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Erik Bais Sent: 09 March 2018 15:15 To: Gert Doering; address-policy-wg at ripe.net Subject: [address-policy-wg] FW: WG chair change Hi Gert, Sander & AP-WG members, Thank you for the email and I would like to formally put my name in the hat. For those that don't know me personally, my name is Erik Bais, Dutch, I'm 45, married for 16 year with my wife Wilhelmina and we have 2 sons. I'm the owner of a Dutch ISP named A2B Internet and I'm one of the co-founders of the IPv4 broker : Prefix Broker. I've lived most of my life in The Netherlands and as a family, we lived for almost a year in the UAE (Dubai) in 2008/2009, when I worked for a US based system integrator and I've worked in Germany for a US based company in the 90's for a year. I have a been working in the ISP community since the 2000. And started A2B Internet in 2010 in The Netherlands. In our work as a connectivity ISP, we started to request AS numbers and IP space for customers in order to get them migrated to our network and while doing so, we noticed some things that needed improvement in the AP policies. That is how it all got started ... I've been the author of the following proposals that have been accepted by the community: https://www.ripe.net/participate/policies/proposals/2011-02 : Removal of multihomed requirement for IPv6 PI # co-author together with Jordi https://www.ripe.net/participate/policies/proposals/2013-04 : Resource Certification for non-RIPE NCC Members # Services WG - allowing PI space holders and Legacy space holders the option for RPKI certification. https://www.ripe.net/participate/policies/proposals/2014-02 : Allow IPv4 PI transfer https://www.ripe.net/participate/policies/proposals/2014-12 : Allow IPv6 Transfers https://www.ripe.net/participate/policies/proposals/2014-13 : Allow AS Number Transfers https://www.ripe.net/participate/policies/proposals/2015-04 : RIPE Resource Transfer Policies And I've been quite active on the discussions on the mailinglist and in the GM's. Besides the various presentations about the policies, I've also done some presentations in the plenary of the RIPE meetings and different WG's about various topics.. Examples are: https://ripe72.ripe.net/archives/video/116/ : Naughty Port project about a different way of making a peering decision based on Network Naughty-ness using a rating system against DDOS's. https://ripe74.ripe.net/archives/video/119/ : IRR Filtering at IXP Route Servers https://ripe75.ripe.net/archives/video/165/ : Pre-Transfer Clean-Up of Abused Prefixes I really like the RIPE community and as an active policy proposer, I think I can say that I have been around the block on the PDP and can work with the sometimes harsh way of communication that a co-chair role has need to deal with in the heat of some discussions. I understand what it requires in effort from time to time and as I'm living in the Netherlands, it makes it easy to visit the Amsterdam RIPE office for me if needed. I hope that the community appreciates the transparent way of communicating and knowledge sharing that I like and that I will be selected as the co-chair for the AP-WG. Regards, Erik Bais From matthieu at herrb.eu Wed May 16 11:40:02 2018 From: matthieu at herrb.eu (Matthieu Herrb) Date: Wed, 16 May 2018 11:40:02 +0200 Subject: [address-policy-wg] 2018-01 New Policy Proposal (Organisation-LIR Clarification in IPv6 Policy) In-Reply-To: <96F06195-3651-4449-9455-8F68A7F64A6A@consulintel.es> References: <20180319164742.GA14764@Space.Net> <96F06195-3651-4449-9455-8F68A7F64A6A@consulintel.es> Message-ID: <20180516094002.GA28942@timmy.laas.fr> On Mon, Mar 19, 2018 at 05:05:18PM +0000, JORDI PALET MARTINEZ via address-policy-wg wrote: > Thanks Gert! > > Further, having no inputs removes all the fun of the PDP! > > In case you missed previous emails, to make it easier for you to comment, I've prepared an on-line diff so you can easily track the proposed changes: > > https://www.diffchecker.com/2mGPoRbo > > Also, the complete text of the proposal is here: > > https://www.ripe.net/participate/policies/proposals/2018-01 > > Now folks don't have any excuse to not comment ;-) Hi, As far as I'm concerned, this looks ok... > > > Regards, > Jordi > > ?-----Mensaje original----- > De: address-policy-wg en nombre de Gert Doering > Fecha: lunes, 19 de marzo de 2018, 16:48 > Para: Marco Schmidt > CC: > Asunto: Re: [address-policy-wg] 2018-01 New Policy Proposal (Organisation-LIR Clarification in IPv6 Policy) > > Dear AP WG, > > On Thu, Feb 22, 2018 at 03:34:25PM +0100, Marco Schmidt wrote: > > A new RIPE Policy proposal, 2018-01, "Organisation-LIR Clarification in IPv6 Policy" is now available for discussion. > > This policy proposal was prompted by the discussion at the last RIPE > meeting, where the NCC brought up the issue that the IPv6 allocation policy > talks about "organization" without ever defining what that is - "one LIR > account", "one legal organization" (which can hold multiple LIR accounts), > etc. > > Jordi volunteered to clean up the text, and here's the proposed changes > - but without some feedback from *you*, we can't clean this up. > > [..] > > We encourage you to review this proposal and send your comments to before 23 March 2018. > > Thus: feedback please. > > Like > > - "the text matches the original intent as I have always understood the > policy, and we should go there" > - "this is not my understanding of the original policy, because ..." > - "never touch a working policy!" > - "I do not see this as a big problem, but the new text works for me" > > Gert Doering > -- APWG chair > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -- Matthieu Herrb -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From jordi.palet at consulintel.es Wed May 16 14:08:49 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 16 May 2018 14:08:49 +0200 Subject: [address-policy-wg] 2018-01 Organisation-LIR Clarification in IPv6 Policy - comments from today meeting Message-ID: <2C43F39F-E3CB-4911-8F56-AB4BBF01414E@consulintel.es> Hi all,? I tried to find the "mismatch" that Peter mention today in the meeting about this proposal text, however was unable to. So, if Peter or somebody else can point to anything more specific, the authors will be happy to provide thougths for alternatives to the mismatching text. Thanks! Regards, Jordi ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From jordi.palet at consulintel.es Wed May 16 14:19:18 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 16 May 2018 14:19:18 +0200 Subject: [address-policy-wg] 2018-02 Assignment Clarification in IPv6 Policy - comments from today meeting Message-ID: Hi all, I've ?been asked to state what is the problem. I think it was clear in my slides, but anyway, here we go with all the problems I see: 1) The current policy text says "Providing another entity with separate addresses (not prefixes)". To me this is inconsistent addresses instead of an address vs not-prefixes. 2) If the end-device need a /64 instead of a single address, as per RFC8273, then it is breaking the actual policy. 3) If we allow sub-assignments, what is then the difference in between IPv6 PA and PI ? So, I think it is clear we have not just one problem? Now, if we want to go further. Do we have the same problem with IPv4 if, for example a university, instead of using NAT, they also sub-assign public IPv4 addresses to students? Inputs? Regards, Jordi ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From alex at vpsville.ru Wed May 16 14:22:09 2018 From: alex at vpsville.ru (Alexey Galaev) Date: Wed, 16 May 2018 15:22:09 +0300 (MSK) Subject: [address-policy-wg] 2018-01 New Policy Proposal (Organisation-LIR Clarification in IPv6 Policy) In-Reply-To: <20180516094002.GA28942@timmy.laas.fr> References: <20180319164742.GA14764@Space.Net> <96F06195-3651-4449-9455-8F68A7F64A6A@consulintel.es> <20180516094002.GA28942@timmy.laas.fr> Message-ID: <430494773.105709.1526473329930.JavaMail.zimbra@vpsville.ru> Dear colleges. I fully support the proposal because it has no negative consequences. It is very small and puts the current policy in the right order. If the new LIR can get the IPv4 network I don't see any reasons why new LIR can't get the IPv6 network. We must support the development of IPv6 but not create problems with IPv6. This proposal is like small fix on github. I don't see any reasons to not approve it. BR, Alexey Galaev +7 985 3608004, http://vpsville.ru http://cloudville.ru ----- Original Message ----- From: "Matthieu Herrb" To: "JORDI PALET MARTINEZ" Cc: address-policy-wg at ripe.net Sent: Wednesday, May 16, 2018 12:40:02 PM Subject: Re: [address-policy-wg] 2018-01 New Policy Proposal (Organisation-LIR Clarification in IPv6 Policy) On Mon, Mar 19, 2018 at 05:05:18PM +0000, JORDI PALET MARTINEZ via address-policy-wg wrote: > Thanks Gert! > > Further, having no inputs removes all the fun of the PDP! > > In case you missed previous emails, to make it easier for you to comment, I've prepared an on-line diff so you can easily track the proposed changes: > > https://www.diffchecker.com/2mGPoRbo > > Also, the complete text of the proposal is here: > > https://www.ripe.net/participate/policies/proposals/2018-01 > > Now folks don't have any excuse to not comment ;-) Hi, As far as I'm concerned, this looks ok... > > > Regards, > Jordi > > ?-----Mensaje original----- > De: address-policy-wg en nombre de Gert Doering > Fecha: lunes, 19 de marzo de 2018, 16:48 > Para: Marco Schmidt > CC: > Asunto: Re: [address-policy-wg] 2018-01 New Policy Proposal (Organisation-LIR Clarification in IPv6 Policy) > > Dear AP WG, > > On Thu, Feb 22, 2018 at 03:34:25PM +0100, Marco Schmidt wrote: > > A new RIPE Policy proposal, 2018-01, "Organisation-LIR Clarification in IPv6 Policy" is now available for discussion. > > This policy proposal was prompted by the discussion at the last RIPE > meeting, where the NCC brought up the issue that the IPv6 allocation policy > talks about "organization" without ever defining what that is - "one LIR > account", "one legal organization" (which can hold multiple LIR accounts), > etc. > > Jordi volunteered to clean up the text, and here's the proposed changes > - but without some feedback from *you*, we can't clean this up. > > [..] > > We encourage you to review this proposal and send your comments to before 23 March 2018. > > Thus: feedback please. > > Like > > - "the text matches the original intent as I have always understood the > policy, and we should go there" > - "this is not my understanding of the original policy, because ..." > - "never touch a working policy!" > - "I do not see this as a big problem, but the new text works for me" > > Gert Doering > -- APWG chair > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -- Matthieu Herrb From jordi.palet at consulintel.es Wed May 16 14:52:57 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 16 May 2018 14:52:57 +0200 Subject: [address-policy-wg] proposal to remove IPv6 PI Message-ID: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> Hi all, For those that haven't been in the meeting, the slides are available at https://ripe76.ripe.net/presentations/97-RIPE-2018-05-v1.pdf I believe we have several problems that my proposal is trying to fix. 1) See my previous email on the clarification of IPv6 PI sub-assignments. Is not just a matter of IPv6, but also IPv4. This is an alternative solution (at least of the IPv6 part - we could do the same for IPv4 of course and also remove IPv4 PI). 2) It was clear in the meeting, as we *all* know, that many folks in the community (and not only in this region) are abusing the policy and they actually use end-user space (PI policies) to *assign* (call it sub-assign if you prefer it), to third parties. 3) It may be the case that this happens because the fee structure. An LIR, currently, pays 1.400 Euros per year (plus one-time setup-fee of 2.000 Euros). And end-user just pay 50 Euros per resource assignment. So, it makes sense to just pay for 50 Euros, and then you may be providing services using NAT+CGN (in the case of IPv4) or a single /64 to each subscriber in the case of IPv6. It is broken, of course, but people do that. 4) The fee scheme is somehow responsible of that as well, as there is in my opinion, unfairness. A big ISP having an IPv6 /20, or /24 or /29 or /32 is paying always the same. This is the only region that have a "flat" rate. 5) We could fix the point above, auditing every end-user. But we could also fix it in a better way by: a) A policy change in the line the one I've proposed (see the slides and the links for a diff) b) Having a single LIR contract, instead of LIR and end-user c) This may be (as an option), also become a way to make a price scheme which is proportional to the amount of resources allocated. Note that we don't need to change the fee scheme, but it is an opportunity for taking a look into that. It may be perfectly possible to keep the cost of end-users as 50 Euros (for a single /48, for example), but having a single contract. I know perfectly that fees are not "policy", however only if we address that we can do correctly the policy. A demonstration of that: When I proposed the IPv6 PI and it reached consensus, it was needed to create the "end-user" contract and the corresponding fee, so is something that we have done before. I know that the proposed text may be very imperfect, for example the usage of "ISPs", but this is not the key now, there are for sure several alternatives to that. For example, we could just differentiate both cases with "LIR that do subsequent distributions initially qualify for /32 up to /29 etc. LIRs that do not do subsequent distributions initially qualify for a /48 for each end-site". So please, don't consider specific text at this point of the discussion. And last, but not least, repeating myself, we could do this just for IPv6, or also work in parallel in a policy proposal for IPv4 PI removal as well. This will be probably the best choice, so we can let the NCC to have a simplified policy, a single contract and consequently less overhead: Simplification for everyone. Thoughts? Regards, Jordi ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From hunekm at gmail.com Wed May 16 16:00:50 2018 From: hunekm at gmail.com (Martin =?utf-8?B?SHVuxJtr?=) Date: Wed, 16 May 2018 16:00:50 +0200 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> Message-ID: <2353324.i1RmT2gKAu@rumburak.ite.tul.cz> Hi Jordi, I must say that I'm strongly against this proposal. Reasons: - Situation between IPv4 and IPv6 is quite different - reasons for canceling IPv4 PI was simply not enough space - Not everyone in the business had to be a LIR and some large non ISP organization could be legitimate user of PI space - Insufficient checks and under-educated LIRs doesn't necessary mean that concept of PI space is bad, only that it is misused Now some details. Even in IPv4 there is still PI space left, not for the ordinary networks, but for the IXPs. It is a fact that there are missuses of IPv6 PI space like ISP running in PI space. But if we want to cast the blame, it would come to the uneducated LIR operators and partially to the RIPE NCC because it did not educate them well (or at least explain when to ask for PI in the LIR portal). Personally, I had to ask my formal upstream (before we became LIR) specifically to make ALLOCATED-BY-LIR object and to make me mnt-lower, step by step because they didn't know how to do that. For such LIR it is easier to ask for PI just because they use to do that for the IPv4. There are also some large companies that would be legitimate to use current PI space. Not every organization had to be in internet business, so it should not be a LIR at all. Current concept of every major end-user to be a LIR is broken because need of IPv4, lets not spoil the IPv6 world the same way. Current PI space misuse could have been solved by more in depth checks. Like if the end user is an ISP, it is most likely misuse. Also if someone asks for PI, RIPE NCC should either pick up the phone or write an e-mail and ask LIR why they want to ask for PI. Can RIPE NCC make video about proper way how to make allocations for LIR's "downstream"/client? Maybe place it in PI assignment wizard in LIR portal. IPv4 shortage just broke the model LIR. Today just too much end users became a LIRs just to be given IPv4 space, but they would never serve as a local internet registry or would not know how to work as LIR. Canceling the IPv6 PI would not help to solve this problem, it would make it even worse, by pushing more and more end users to became LIR when they are actually not one. Best regards Martin Dne st?eda 16. kv?tna 2018 14:52:57 CEST, JORDI PALET MARTINEZ via address-policy-wg napsal(a): > Hi all, > > For those that haven't been in the meeting, the slides are available at https://ripe76.ripe.net/presentations/97-RIPE-2018-05-v1.pdf > > I believe we have several problems that my proposal is trying to fix. > > 1) See my previous email on the clarification of IPv6 PI sub-assignments. Is not just a matter of IPv6, but also IPv4. This is an alternative solution (at least of the IPv6 part - we could do the same for IPv4 of course and also remove IPv4 PI). > > 2) It was clear in the meeting, as we *all* know, that many folks in the community (and not only in this region) are abusing the policy and they actually use end-user space (PI policies) to *assign* (call it sub-assign if you prefer it), to third parties. > > 3) It may be the case that this happens because the fee structure. An LIR, currently, pays 1.400 Euros per year (plus one-time setup-fee of 2.000 Euros). And end-user just pay 50 Euros per resource assignment. So, it makes sense to just pay for 50 Euros, and then you may be providing services using NAT+CGN (in the case of IPv4) or a single /64 to each subscriber in the case of IPv6. It is broken, of course, but people do that. > > 4) The fee scheme is somehow responsible of that as well, as there is in my opinion, unfairness. A big ISP having an IPv6 /20, or /24 or /29 or /32 is paying always the same. This is the only region that have a "flat" rate. > > 5) We could fix the point above, auditing every end-user. But we could also fix it in a better way by: > a) A policy change in the line the one I've proposed (see the slides and the links for a diff) > b) Having a single LIR contract, instead of LIR and end-user > c) This may be (as an option), also become a way to make a price scheme which is proportional to the amount of resources allocated. > > Note that we don't need to change the fee scheme, but it is an opportunity for taking a look into that. It may be perfectly possible to keep the cost of end-users as 50 Euros (for a single /48, for example), but having a single contract. I know perfectly that fees are not "policy", however only if we address that we can do correctly the policy. A demonstration of that: When I proposed the IPv6 PI and it reached consensus, it was needed to create the "end-user" contract and the corresponding fee, so is something that we have done before. > > I know that the proposed text may be very imperfect, for example the usage of "ISPs", but this is not the key now, there are for sure several alternatives to that. For example, we could just differentiate both cases with "LIR that do subsequent distributions initially qualify for /32 up to /29 etc. LIRs that do not do subsequent distributions initially qualify for a /48 for each end-site". So please, don't consider specific text at this point of the discussion. > > And last, but not least, repeating myself, we could do this just for IPv6, or also work in parallel in a policy proposal for IPv4 PI removal as well. This will be probably the best choice, so we can let the NCC to have a simplified policy, a single contract and consequently less overhead: Simplification for everyone. > > Thoughts? > > > Regards, > Jordi > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From jordi.palet at consulintel.es Wed May 16 16:10:13 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 16 May 2018 16:10:13 +0200 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: <2353324.i1RmT2gKAu@rumburak.ite.tul.cz> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> <2353324.i1RmT2gKAu@rumburak.ite.tul.cz> Message-ID: <87C520BE-4366-40F6-A1B1-19F933EC4F61@consulintel.es> Hi Martin, I'm clear about the IPv4 situation. No discussion on that. I also understand that both (ISP for special infrastructure and also large non-ISP) need addressing space. Call it PI or PA is another question. Having a single contract doesn't goes against the need for both kind of organizations. I think we both agree. What I'm saying is that there is no need to have both into different policies if are able to simplify for both organizations to have a single contract and a single policy (with of course, require a small different justification mechanism - or may be not even to make it much simpler). Can you tell me why you believe we need to keep them *isolated* ? I mean specific needs that makes impossible to accommodate both into a single policy? The only *real* difference in the policy is that one starts with /48 per end-site, the other with /32. Anything else? Regards, Jordi ?-----Mensaje original----- De: address-policy-wg en nombre de Martin Hun?k Fecha: mi?rcoles, 16 de mayo de 2018, 16:01 Para: , JORDI PALET MARTINEZ Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI Hi Jordi, I must say that I'm strongly against this proposal. Reasons: - Situation between IPv4 and IPv6 is quite different - reasons for canceling IPv4 PI was simply not enough space - Not everyone in the business had to be a LIR and some large non ISP organization could be legitimate user of PI space - Insufficient checks and under-educated LIRs doesn't necessary mean that concept of PI space is bad, only that it is misused Now some details. Even in IPv4 there is still PI space left, not for the ordinary networks, but for the IXPs. It is a fact that there are missuses of IPv6 PI space like ISP running in PI space. But if we want to cast the blame, it would come to the uneducated LIR operators and partially to the RIPE NCC because it did not educate them well (or at least explain when to ask for PI in the LIR portal). Personally, I had to ask my formal upstream (before we became LIR) specifically to make ALLOCATED-BY-LIR object and to make me mnt-lower, step by step because they didn't know how to do that. For such LIR it is easier to ask for PI just because they use to do that for the IPv4. There are also some large companies that would be legitimate to use current PI space. Not every organization had to be in internet business, so it should not be a LIR at all. Current concept of every major end-user to be a LIR is broken because need of IPv4, lets not spoil the IPv6 world the same way. Current PI space misuse could have been solved by more in depth checks. Like if the end user is an ISP, it is most likely misuse. Also if someone asks for PI, RIPE NCC should either pick up the phone or write an e-mail and ask LIR why they want to ask for PI. Can RIPE NCC make video about proper way how to make allocations for LIR's "downstream"/client? Maybe place it in PI assignment wizard in LIR portal. IPv4 shortage just broke the model LIR. Today just too much end users became a LIRs just to be given IPv4 space, but they would never serve as a local internet registry or would not know how to work as LIR. Canceling the IPv6 PI would not help to solve this problem, it would make it even worse, by pushing more and more end users to became LIR when they are actually not one. Best regards Martin Dne st?eda 16. kv?tna 2018 14:52:57 CEST, JORDI PALET MARTINEZ via address-policy-wg napsal(a): > Hi all, > > For those that haven't been in the meeting, the slides are available at https://ripe76.ripe.net/presentations/97-RIPE-2018-05-v1.pdf > > I believe we have several problems that my proposal is trying to fix. > > 1) See my previous email on the clarification of IPv6 PI sub-assignments. Is not just a matter of IPv6, but also IPv4. This is an alternative solution (at least of the IPv6 part - we could do the same for IPv4 of course and also remove IPv4 PI). > > 2) It was clear in the meeting, as we *all* know, that many folks in the community (and not only in this region) are abusing the policy and they actually use end-user space (PI policies) to *assign* (call it sub-assign if you prefer it), to third parties. > > 3) It may be the case that this happens because the fee structure. An LIR, currently, pays 1.400 Euros per year (plus one-time setup-fee of 2.000 Euros). And end-user just pay 50 Euros per resource assignment. So, it makes sense to just pay for 50 Euros, and then you may be providing services using NAT+CGN (in the case of IPv4) or a single /64 to each subscriber in the case of IPv6. It is broken, of course, but people do that. > > 4) The fee scheme is somehow responsible of that as well, as there is in my opinion, unfairness. A big ISP having an IPv6 /20, or /24 or /29 or /32 is paying always the same. This is the only region that have a "flat" rate. > > 5) We could fix the point above, auditing every end-user. But we could also fix it in a better way by: > a) A policy change in the line the one I've proposed (see the slides and the links for a diff) > b) Having a single LIR contract, instead of LIR and end-user > c) This may be (as an option), also become a way to make a price scheme which is proportional to the amount of resources allocated. > > Note that we don't need to change the fee scheme, but it is an opportunity for taking a look into that. It may be perfectly possible to keep the cost of end-users as 50 Euros (for a single /48, for example), but having a single contract. I know perfectly that fees are not "policy", however only if we address that we can do correctly the policy. A demonstration of that: When I proposed the IPv6 PI and it reached consensus, it was needed to create the "end-user" contract and the corresponding fee, so is something that we have done before. > > I know that the proposed text may be very imperfect, for example the usage of "ISPs", but this is not the key now, there are for sure several alternatives to that. For example, we could just differentiate both cases with "LIR that do subsequent distributions initially qualify for /32 up to /29 etc. LIRs that do not do subsequent distributions initially qualify for a /48 for each end-site". So please, don't consider specific text at this point of the discussion. > > And last, but not least, repeating myself, we could do this just for IPv6, or also work in parallel in a policy proposal for IPv4 PI removal as well. This will be probably the best choice, so we can let the NCC to have a simplified policy, a single contract and consequently less overhead: Simplification for everyone. > > Thoughts? > > > Regards, > Jordi > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From gert at space.net Wed May 16 16:11:24 2018 From: gert at space.net (Gert Doering) Date: Wed, 16 May 2018 16:11:24 +0200 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> Message-ID: <20180516141124.GC89741@Space.Net> Hi, On Wed, May 16, 2018 at 02:52:57PM +0200, JORDI PALET MARTINEZ via address-policy-wg wrote: > 2) It was clear in the meeting, as we *all* know, that many folks in the community (and not only in this region) are abusing the policy and they actually use end-user space (PI policies) to *assign* (call it sub-assign if you prefer it), to third parties. In IPv4, the PI policy is different and explicitely allows numbering of transit networks to customer sites (= "my router and their router") from PI space. So running an ISP on PI space is *not* "abusing the policy". Which has been pointed out quite a few times in APWG sessions and nobody saw the need to go for a change here (and since IPv4 PI is now gone, I'm not sure it's a useful usage of the WG's time to spend it on IPv4 PI) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From wusel+ml at uu.org Wed May 16 16:46:57 2018 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Wed, 16 May 2018 16:46:57 +0200 Subject: [address-policy-wg] 2018-02 Assignment Clarification in IPv6 Policy - comments from today meeting In-Reply-To: References: Message-ID: <53c22ca9-dce4-6782-61bf-9a0644a580c7@uu.org> On 16.05.2018 14:19, JORDI PALET MARTINEZ via address-policy-wg wrote: > Hi all, > > I've ?been asked to state what is the problem. > > I think it was clear in my slides, but anyway, here we go with all the problems I see: > > 1) The current policy text says "Providing another entity with separate addresses (not prefixes)". > To me this is inconsistent addresses instead of an address vs not-prefixes. I think I mentioned this on 2016-04 already; any single address is always a prefix as well, /128 in v6. But your slide 3 shows nicely why I strictly oppose more meddling with this paragraph. We went from 42 words in ?2.6 Assign? to 98 in the current policy text, which your proposal would boost to a staggering 134 words. And that's without the necessary ? but yet missing ? definitions of ?non-permanently? or what happens on links that are not ?operated? by the assigment holder (i. e. a link a peer operates cannot use numbers from my assignment?). Not to mention the loophole that narrow band services are explicitely are allowed now ? given 100 GBit/sec links are common these days, 10 to 100 MBit/sec is definitely narrow band today, right? But there is a point everyone seems to happily ignore: The text discussed last time, as well as this time, changes the basic definition of what an assignment is and "to assign" means. As such, that definition applies everywhere where the policy document talks about assignments. Like e. g. in ?5.4.3. Assignment to operator's infrastructure?: ?An organisation (i.e. ISP/LIR) may assign a network prefix per PoP as the service infrastructure of an IPv6 service operator. Each assignment to a PoP is regarded as one assignment regardless of the number of users using the PoP. A separate assignment can be obtained for the in-house operations of the operator.? The more text we put into 2.6, the more difficult it will become to not violate the policy, for End Users, ISPs and even for LIRs. Any change to "2.6 Assign" applies to PA and PI space alike. > 3) If we allow sub-assignments, what is then the difference in between IPv6 PA and PI ? You are barking at the wrong tree. "2.6 Assign" applies to PI and PA and disencourages sub-assignments (of any assigned space) "to other parties" anyway. > So, I think it is clear we have not just one problem? I do not see a real problem with the text of ripe-699 ? unless I start nit-picking and take the policy apart, word by word. If one *wants*, the *intention* of the policy can be understood. If one does not want to understand the intention, more words will simply make things worse, not better. Regards, -kai From lists at velder.li Wed May 16 16:50:02 2018 From: lists at velder.li (Patrick Velder) Date: Wed, 16 May 2018 16:50:02 +0200 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> Message-ID: <7036440d-9cca-26fd-8d0b-16db790364b5@velder.li> Hi, I am against the proposal, but I agree to #4 (from the IPv4 view, too). Regards Patrick On 16.05.2018 14:52, JORDI PALET MARTINEZ via address-policy-wg wrote: > Hi all, > > For those that haven't been in the meeting, the slides are available at https://ripe76.ripe.net/presentations/97-RIPE-2018-05-v1.pdf > > I believe we have several problems that my proposal is trying to fix. > > 1) See my previous email on the clarification of IPv6 PI sub-assignments. Is not just a matter of IPv6, but also IPv4. This is an alternative solution (at least of the IPv6 part - we could do the same for IPv4 of course and also remove IPv4 PI). > > 2) It was clear in the meeting, as we *all* know, that many folks in the community (and not only in this region) are abusing the policy and they actually use end-user space (PI policies) to *assign* (call it sub-assign if you prefer it), to third parties. > > 3) It may be the case that this happens because the fee structure. An LIR, currently, pays 1.400 Euros per year (plus one-time setup-fee of 2.000 Euros). And end-user just pay 50 Euros per resource assignment. So, it makes sense to just pay for 50 Euros, and then you may be providing services using NAT+CGN (in the case of IPv4) or a single /64 to each subscriber in the case of IPv6. It is broken, of course, but people do that. > > 4) The fee scheme is somehow responsible of that as well, as there is in my opinion, unfairness. A big ISP having an IPv6 /20, or /24 or /29 or /32 is paying always the same. This is the only region that have a "flat" rate. > > 5) We could fix the point above, auditing every end-user. But we could also fix it in a better way by: > a) A policy change in the line the one I've proposed (see the slides and the links for a diff) > b) Having a single LIR contract, instead of LIR and end-user > c) This may be (as an option), also become a way to make a price scheme which is proportional to the amount of resources allocated. > > Note that we don't need to change the fee scheme, but it is an opportunity for taking a look into that. It may be perfectly possible to keep the cost of end-users as 50 Euros (for a single /48, for example), but having a single contract. I know perfectly that fees are not "policy", however only if we address that we can do correctly the policy. A demonstration of that: When I proposed the IPv6 PI and it reached consensus, it was needed to create the "end-user" contract and the corresponding fee, so is something that we have done before. > > I know that the proposed text may be very imperfect, for example the usage of "ISPs", but this is not the key now, there are for sure several alternatives to that. For example, we could just differentiate both cases with "LIR that do subsequent distributions initially qualify for /32 up to /29 etc. LIRs that do not do subsequent distributions initially qualify for a /48 for each end-site". So please, don't consider specific text at this point of the discussion. > > And last, but not least, repeating myself, we could do this just for IPv6, or also work in parallel in a policy proposal for IPv4 PI removal as well. This will be probably the best choice, so we can let the NCC to have a simplified policy, a single contract and consequently less overhead: Simplification for everyone. > > Thoughts? > > > Regards, > Jordi > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > From gert at space.net Wed May 16 17:02:58 2018 From: gert at space.net (Gert Doering) Date: Wed, 16 May 2018 17:02:58 +0200 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: <7036440d-9cca-26fd-8d0b-16db790364b5@velder.li> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> <7036440d-9cca-26fd-8d0b-16db790364b5@velder.li> Message-ID: <20180516150258.GD89741@Space.Net> Hi, On Wed, May 16, 2018 at 04:50:02PM +0200, Patrick Velder wrote: > I am against the proposal, but I agree to #4 (from the IPv4 view, too). Fee structure is unfortunately something we cannot fix (or even work on) here in the APWG. Fees are decided by the AGM - and the "one size fits all" fee came due to member request & vote (we started with a scaled fee by membership size). Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From hunekm at gmail.com Wed May 16 17:27:56 2018 From: hunekm at gmail.com (Martin =?utf-8?B?SHVuxJtr?=) Date: Wed, 16 May 2018 17:27:56 +0200 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: <87C520BE-4366-40F6-A1B1-19F933EC4F61@consulintel.es> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> <2353324.i1RmT2gKAu@rumburak.ite.tul.cz> <87C520BE-4366-40F6-A1B1-19F933EC4F61@consulintel.es> Message-ID: <2116215.Frit7E0hTN@rumburak.ite.tul.cz> Hi Jordi, As I understand it, the PA is only for a LIR and PI is also for sponsored organization. Also the PI is solely for the end user infrastructure and and PA can be further allocated or assigned. I'm not competent enough to tell if it is better to have the same contract with members and non-members, maybe someone from RIPE NCC can answer that. I think that they should be isolated because they should be used for different things. PA for networks with single upstream - they should receive ALLOCATED-BY-LIR from LIR's PA. PI for customers with the second upstream. On the other hand we all know that PI is used as small PA, without editing RIPE DB, of course. By removing PI, you would had to allow non-members to receive PA or you would had to force every current PI holder to became LIR. I know that most of the new members are in RIPE just for IPv4, but in the distant IPv6 only future, what would be the result of such change? What would be the reason to be a member in such future? In my opinion PI should still be here, but only for a special cases, non-ISP non-LIR organizations. So if there will be any use of PI space by ISP for its clients, it should be immediately reclaimed by RIPE NCC. Also LIR should not be entitled to claim PI for itself. But this is just my point of view. Sincerely, Martin Dne st?eda 16. kv?tna 2018 16:10:13 CEST, JORDI PALET MARTINEZ via address-policy-wg napsal(a): > Hi Martin, > > I'm clear about the IPv4 situation. No discussion on that. > > I also understand that both (ISP for special infrastructure and also large non-ISP) need addressing space. Call it PI or PA is another question. > > Having a single contract doesn't goes against the need for both kind of organizations. > > I think we both agree. What I'm saying is that there is no need to have both into different policies if are able to simplify for both organizations to have a single contract and a single policy (with of course, require a small different justification mechanism - or may be not even to make it much simpler). > > Can you tell me why you believe we need to keep them *isolated* ? I mean specific needs that makes impossible to accommodate both into a single policy? > > The only *real* difference in the policy is that one starts with /48 per end-site, the other with /32. Anything else? > > Regards, > Jordi > > > > ?-----Mensaje original----- > De: address-policy-wg en nombre de Martin Hun?k > Fecha: mi?rcoles, 16 de mayo de 2018, 16:01 > Para: , JORDI PALET MARTINEZ > Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI > > Hi Jordi, > > I must say that I'm strongly against this proposal. > > Reasons: > - Situation between IPv4 and IPv6 is quite different - reasons for canceling IPv4 PI was simply not enough space > - Not everyone in the business had to be a LIR and some large non ISP organization could be legitimate user of PI space > - Insufficient checks and under-educated LIRs doesn't necessary mean that concept of PI space is bad, only that it is misused > > Now some details. Even in IPv4 there is still PI space left, not for the ordinary networks, but for the IXPs. It is a fact that there are missuses of IPv6 PI space like ISP running in PI space. But if we want to cast the blame, it would come to the uneducated LIR operators and partially to the RIPE NCC because it did not educate them well (or at least explain when to ask for PI in the LIR portal). > > Personally, I had to ask my formal upstream (before we became LIR) specifically to make ALLOCATED-BY-LIR object and to make me mnt-lower, step by step because they didn't know how to do that. For such LIR it is easier to ask for PI just because they use to do that for the IPv4. > > There are also some large companies that would be legitimate to use current PI space. Not every organization had to be in internet business, so it should not be a LIR at all. Current concept of every major end-user to be a LIR is broken because need of IPv4, lets not spoil the IPv6 world the same way. > > Current PI space misuse could have been solved by more in depth checks. Like if the end user is an ISP, it is most likely misuse. Also if someone asks for PI, RIPE NCC should either pick up the phone or write an e-mail and ask LIR why they want to ask for PI. > > Can RIPE NCC make video about proper way how to make allocations for LIR's "downstream"/client? Maybe place it in PI assignment wizard in LIR portal. > > IPv4 shortage just broke the model LIR. Today just too much end users became a LIRs just to be given IPv4 space, but they would never serve as a local internet registry or would not know how to work as LIR. Canceling the IPv6 PI would not help to solve this problem, it would make it even worse, by pushing more and more end users to became LIR when they are actually not one. > > Best regards > Martin > > Dne st?eda 16. kv?tna 2018 14:52:57 CEST, JORDI PALET MARTINEZ via address-policy-wg napsal(a): > > Hi all, > > > > For those that haven't been in the meeting, the slides are available at https://ripe76.ripe.net/presentations/97-RIPE-2018-05-v1.pdf > > > > I believe we have several problems that my proposal is trying to fix. > > > > 1) See my previous email on the clarification of IPv6 PI sub-assignments. Is not just a matter of IPv6, but also IPv4. This is an alternative solution (at least of the IPv6 part - we could do the same for IPv4 of course and also remove IPv4 PI). > > > > 2) It was clear in the meeting, as we *all* know, that many folks in the community (and not only in this region) are abusing the policy and they actually use end-user space (PI policies) to *assign* (call it sub-assign if you prefer it), to third parties. > > > > 3) It may be the case that this happens because the fee structure. An LIR, currently, pays 1.400 Euros per year (plus one-time setup-fee of 2.000 Euros). And end-user just pay 50 Euros per resource assignment. So, it makes sense to just pay for 50 Euros, and then you may be providing services using NAT+CGN (in the case of IPv4) or a single /64 to each subscriber in the case of IPv6. It is broken, of course, but people do that. > > > > 4) The fee scheme is somehow responsible of that as well, as there is in my opinion, unfairness. A big ISP having an IPv6 /20, or /24 or /29 or /32 is paying always the same. This is the only region that have a "flat" rate. > > > > 5) We could fix the point above, auditing every end-user. But we could also fix it in a better way by: > > a) A policy change in the line the one I've proposed (see the slides and the links for a diff) > > b) Having a single LIR contract, instead of LIR and end-user > > c) This may be (as an option), also become a way to make a price scheme which is proportional to the amount of resources allocated. > > > > Note that we don't need to change the fee scheme, but it is an opportunity for taking a look into that. It may be perfectly possible to keep the cost of end-users as 50 Euros (for a single /48, for example), but having a single contract. I know perfectly that fees are not "policy", however only if we address that we can do correctly the policy. A demonstration of that: When I proposed the IPv6 PI and it reached consensus, it was needed to create the "end-user" contract and the corresponding fee, so is something that we have done before. > > > > I know that the proposed text may be very imperfect, for example the usage of "ISPs", but this is not the key now, there are for sure several alternatives to that. For example, we could just differentiate both cases with "LIR that do subsequent distributions initially qualify for /32 up to /29 etc. LIRs that do not do subsequent distributions initially qualify for a /48 for each end-site". So please, don't consider specific text at this point of the discussion. > > > > And last, but not least, repeating myself, we could do this just for IPv6, or also work in parallel in a policy proposal for IPv4 PI removal as well. This will be probably the best choice, so we can let the NCC to have a simplified policy, a single contract and consequently less overhead: Simplification for everyone. > > > > Thoughts? > > > > > > Regards, > > Jordi > > > > > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.consulintel.es > > The IPv6 Company > > > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > > > > > > > > > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From jordi.palet at consulintel.es Wed May 16 17:33:33 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 16 May 2018 17:33:33 +0200 Subject: [address-policy-wg] 2018-02 Assignment Clarification in IPv6 Policy - comments from today meeting In-Reply-To: <53c22ca9-dce4-6782-61bf-9a0644a580c7@uu.org> References: <53c22ca9-dce4-6782-61bf-9a0644a580c7@uu.org> Message-ID: <38E24466-EDEB-4B44-897C-FD565DCC1AC2@consulintel.es> Hi Kai, Below, in-line. Regards, Jordi ?-----Mensaje original----- De: address-policy-wg en nombre de Kai 'wusel' Siering Organizaci?n: Unseen University, Department of Magic Mails Fecha: mi?rcoles, 16 de mayo de 2018, 16:47 Para: Asunto: Re: [address-policy-wg] 2018-02 Assignment Clarification in IPv6 Policy - comments from today meeting On 16.05.2018 14:19, JORDI PALET MARTINEZ via address-policy-wg wrote: > Hi all, > > I've ?been asked to state what is the problem. > > I think it was clear in my slides, but anyway, here we go with all the problems I see: > > 1) The current policy text says "Providing another entity with separate addresses (not prefixes)". > To me this is inconsistent addresses instead of an address vs not-prefixes. I think I mentioned this on 2016-04 already; any single address is always a prefix as well, /128 in v6. So, to make sure I understood your point. You think that a single /128 prefix is ok to be sub-assigned (as per the current policy), but a single /64 prefix is not? Or you will agree in a change that only fix that? But your slide 3 shows nicely why I strictly oppose more meddling with this paragraph. We went from 42 words in ?2.6 Assign? to 98 in the current policy text, which your proposal would boost to a staggering 134 words. And that's without the necessary ? but yet missing ? definitions of ?non-permanently? or what happens on links that are not ?operated? by the assigment holder (i. e. a link a peer operates cannot use numbers from my assignment?). Not to mention the loophole that narrow band services are explicitely are allowed now ? given 100 GBit/sec links are common these days, 10 to 100 MBit/sec is definitely narrow band today, right? Regarding the specific wording, you're totally right and we should decide *if* there is a way to re-formulate it. But there is a point everyone seems to happily ignore: The text discussed last time, as well as this time, changes the basic definition of what an assignment is and "to assign" means. As such, that definition applies everywhere where the policy document talks about assignments. Like e. g. in ?5.4.3. Assignment to operator's infrastructure?: ?An organisation (i.e. ISP/LIR) may assign a network prefix per PoP as the service infrastructure of an IPv6 service operator. Each assignment to a PoP is regarded as one assignment regardless of the number of users using the PoP. A separate assignment can be obtained for the in-house operations of the operator.? That's the reason I initially suggested, even when discussing 2016-04, that the text should be only in the IPv6 PI section ... the consensus was in the other direction. The more text we put into 2.6, the more difficult it will become to not violate the policy, for End Users, ISPs and even for LIRs. Any change to "2.6 Assign" applies to PA and PI space alike. > 3) If we allow sub-assignments, what is then the difference in between IPv6 PA and PI ? You are barking at the wrong tree. "2.6 Assign" applies to PI and PA and disencourages sub-assignments (of any assigned space) "to other parties" anyway. > So, I think it is clear we have not just one problem? I do not see a real problem with the text of ripe-699 ? unless I start nit-picking and take the policy apart, word by word. If one *wants*, the *intention* of the policy can be understood. If one does not want to understand the intention, more words will simply make things worse, not better. This is the big problem in my opinion, and I actually forgot the mention it before. I think policy must be as much as possible, a text which has only one interpretation, even if that means it is longer. Otherwise, and I explained this in emails when discussing 2016-04, people that "follows" the policy process has advantage in terms of interpretation vs a newcomer that will read only the *policy text*, but not the impact analysis, and all the discussions used to clarify the policy text. Regards, -kai ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From jordi.palet at consulintel.es Wed May 16 17:45:01 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 16 May 2018 17:45:01 +0200 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: <2116215.Frit7E0hTN@rumburak.ite.tul.cz> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> <2353324.i1RmT2gKAu@rumburak.ite.tul.cz> <87C520BE-4366-40F6-A1B1-19F933EC4F61@consulintel.es> <2116215.Frit7E0hTN@rumburak.ite.tul.cz> Message-ID: <147471F6-091C-4E3D-879A-8089C70DD140@consulintel.es> Below, in-line. Regards, Jordi ?-----Mensaje original----- De: address-policy-wg en nombre de Martin Hun?k Fecha: mi?rcoles, 16 de mayo de 2018, 17:28 Para: , JORDI PALET MARTINEZ Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI Hi Jordi, As I understand it, the PA is only for a LIR and PI is also for sponsored organization. Also the PI is solely for the end user infrastructure and and PA can be further allocated or assigned. This is our actual definition. We can change it whenever we want. What I'm asking is what is the *real* distinction among them. Forget for a minute in contracts, fee structure and so on. There is no need to call the same with different names if we don't want. I'm calling here for simplicity. Once we remove the sub-assignment obstacle, there is not anymore a difference. I'm not competent enough to tell if it is better to have the same contract with members and non-members, maybe someone from RIPE NCC can answer that. I think that they should be isolated because they should be used for different things. PA for networks with single upstream - they should receive ALLOCATED-BY-LIR from LIR's PA. PI for customers with the second upstream. On the other hand we all know that PI is used as small PA, without editing RIPE DB, of course. There is not anymore an obligation, for many years, to have multihoming. So, no difference here. By removing PI, you would had to allow non-members to receive PA or you would had to force every current PI holder to became LIR. I know that most of the new members are in RIPE just for IPv4, but in the distant IPv6 only future, what would be the result of such change? What would be the reason to be a member in such future? Yes, that's the idea, please see my slides. PI holders will need to become members, maybe the fee will get an increase (something on the line of a small one-time setup fee and later on a proportion of the cost of a /32 if you are getting only a /48, etc., but this is for the membership to decide). What we all win with that is a fairer cost distribution and also an easier way to make sure that the rules are followed and nobody tricks the rules using a PI as PA. Specially for the NCC is much simpler. In my opinion PI should still be here, but only for a special cases, non-ISP non-LIR organizations. So if there will be any use of PI space by ISP for its clients, it should be immediately reclaimed by RIPE NCC. Also LIR should not be entitled to claim PI for itself. But this is just my point of view. So then, again, let's roll back 2016-04, because is non-sense that somebody instead of using the addressing space for their own organization as end-user, is using it for a hotspot or datacenter. I'm more and more convinced as we exchange emails on this, that either we clarify very well what is a sub-assignment (and if you follow the last couple of emails on that discussion you will see how difficult may be to clarify that with a "short" text), or we just put all in the same "class" of addressing space. Sincerely, Martin Dne st?eda 16. kv?tna 2018 16:10:13 CEST, JORDI PALET MARTINEZ via address-policy-wg napsal(a): > Hi Martin, > > I'm clear about the IPv4 situation. No discussion on that. > > I also understand that both (ISP for special infrastructure and also large non-ISP) need addressing space. Call it PI or PA is another question. > > Having a single contract doesn't goes against the need for both kind of organizations. > > I think we both agree. What I'm saying is that there is no need to have both into different policies if are able to simplify for both organizations to have a single contract and a single policy (with of course, require a small different justification mechanism - or may be not even to make it much simpler). > > Can you tell me why you believe we need to keep them *isolated* ? I mean specific needs that makes impossible to accommodate both into a single policy? > > The only *real* difference in the policy is that one starts with /48 per end-site, the other with /32. Anything else? > > Regards, > Jordi > > > > ?-----Mensaje original----- > De: address-policy-wg en nombre de Martin Hun?k > Fecha: mi?rcoles, 16 de mayo de 2018, 16:01 > Para: , JORDI PALET MARTINEZ > Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI > > Hi Jordi, > > I must say that I'm strongly against this proposal. > > Reasons: > - Situation between IPv4 and IPv6 is quite different - reasons for canceling IPv4 PI was simply not enough space > - Not everyone in the business had to be a LIR and some large non ISP organization could be legitimate user of PI space > - Insufficient checks and under-educated LIRs doesn't necessary mean that concept of PI space is bad, only that it is misused > > Now some details. Even in IPv4 there is still PI space left, not for the ordinary networks, but for the IXPs. It is a fact that there are missuses of IPv6 PI space like ISP running in PI space. But if we want to cast the blame, it would come to the uneducated LIR operators and partially to the RIPE NCC because it did not educate them well (or at least explain when to ask for PI in the LIR portal). > > Personally, I had to ask my formal upstream (before we became LIR) specifically to make ALLOCATED-BY-LIR object and to make me mnt-lower, step by step because they didn't know how to do that. For such LIR it is easier to ask for PI just because they use to do that for the IPv4. > > There are also some large companies that would be legitimate to use current PI space. Not every organization had to be in internet business, so it should not be a LIR at all. Current concept of every major end-user to be a LIR is broken because need of IPv4, lets not spoil the IPv6 world the same way. > > Current PI space misuse could have been solved by more in depth checks. Like if the end user is an ISP, it is most likely misuse. Also if someone asks for PI, RIPE NCC should either pick up the phone or write an e-mail and ask LIR why they want to ask for PI. > > Can RIPE NCC make video about proper way how to make allocations for LIR's "downstream"/client? Maybe place it in PI assignment wizard in LIR portal. > > IPv4 shortage just broke the model LIR. Today just too much end users became a LIRs just to be given IPv4 space, but they would never serve as a local internet registry or would not know how to work as LIR. Canceling the IPv6 PI would not help to solve this problem, it would make it even worse, by pushing more and more end users to became LIR when they are actually not one. > > Best regards > Martin > > Dne st?eda 16. kv?tna 2018 14:52:57 CEST, JORDI PALET MARTINEZ via address-policy-wg napsal(a): > > Hi all, > > > > For those that haven't been in the meeting, the slides are available at https://ripe76.ripe.net/presentations/97-RIPE-2018-05-v1.pdf > > > > I believe we have several problems that my proposal is trying to fix. > > > > 1) See my previous email on the clarification of IPv6 PI sub-assignments. Is not just a matter of IPv6, but also IPv4. This is an alternative solution (at least of the IPv6 part - we could do the same for IPv4 of course and also remove IPv4 PI). > > > > 2) It was clear in the meeting, as we *all* know, that many folks in the community (and not only in this region) are abusing the policy and they actually use end-user space (PI policies) to *assign* (call it sub-assign if you prefer it), to third parties. > > > > 3) It may be the case that this happens because the fee structure. An LIR, currently, pays 1.400 Euros per year (plus one-time setup-fee of 2.000 Euros). And end-user just pay 50 Euros per resource assignment. So, it makes sense to just pay for 50 Euros, and then you may be providing services using NAT+CGN (in the case of IPv4) or a single /64 to each subscriber in the case of IPv6. It is broken, of course, but people do that. > > > > 4) The fee scheme is somehow responsible of that as well, as there is in my opinion, unfairness. A big ISP having an IPv6 /20, or /24 or /29 or /32 is paying always the same. This is the only region that have a "flat" rate. > > > > 5) We could fix the point above, auditing every end-user. But we could also fix it in a better way by: > > a) A policy change in the line the one I've proposed (see the slides and the links for a diff) > > b) Having a single LIR contract, instead of LIR and end-user > > c) This may be (as an option), also become a way to make a price scheme which is proportional to the amount of resources allocated. > > > > Note that we don't need to change the fee scheme, but it is an opportunity for taking a look into that. It may be perfectly possible to keep the cost of end-users as 50 Euros (for a single /48, for example), but having a single contract. I know perfectly that fees are not "policy", however only if we address that we can do correctly the policy. A demonstration of that: When I proposed the IPv6 PI and it reached consensus, it was needed to create the "end-user" contract and the corresponding fee, so is something that we have done before. > > > > I know that the proposed text may be very imperfect, for example the usage of "ISPs", but this is not the key now, there are for sure several alternatives to that. For example, we could just differentiate both cases with "LIR that do subsequent distributions initially qualify for /32 up to /29 etc. LIRs that do not do subsequent distributions initially qualify for a /48 for each end-site". So please, don't consider specific text at this point of the discussion. > > > > And last, but not least, repeating myself, we could do this just for IPv6, or also work in parallel in a policy proposal for IPv4 PI removal as well. This will be probably the best choice, so we can let the NCC to have a simplified policy, a single contract and consequently less overhead: Simplification for everyone. > > > > Thoughts? > > > > > > Regards, > > Jordi > > > > > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.consulintel.es > > The IPv6 Company > > > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > > > > > > > > > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From hunekm at gmail.com Wed May 16 18:29:15 2018 From: hunekm at gmail.com (Martin =?utf-8?B?SHVuxJtr?=) Date: Wed, 16 May 2018 18:29:15 +0200 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: <147471F6-091C-4E3D-879A-8089C70DD140@consulintel.es> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> <2116215.Frit7E0hTN@rumburak.ite.tul.cz> <147471F6-091C-4E3D-879A-8089C70DD140@consulintel.es> Message-ID: <2182481.LFyoZQ4taB@rumburak.ite.tul.cz> in-line Regards, Martin Dne st?eda 16. kv?tna 2018 17:45:01 CEST, JORDI PALET MARTINEZ via address-policy-wg napsal(a): > Below, in-line. > > Regards, > Jordi > > > > ?-----Mensaje original----- > De: address-policy-wg en nombre de Martin Hun?k > Fecha: mi?rcoles, 16 de mayo de 2018, 17:28 > Para: , JORDI PALET MARTINEZ > Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI > >> Hi Jordi, > >> As I understand it, the PA is only for a LIR and PI is also for sponsored organization. Also the PI is solely for the end user infrastructure and and PA can be further allocated or assigned. > > This is our actual definition. We can change it whenever we want. What I'm asking is what is the *real* distinction among them. Forget for a minute in contracts, fee structure and so on. There is no need to call the same with different names if we don't want. I'm calling here for simplicity. Once we remove the sub-assignment obstacle, there is not anymore a difference. Discussion should be about, if we want to / should remove such *obstacle*. I would personally prefer that policy about PI space would stay the same. Just RIPE NCC should be more investigative and restrictive when assigning those. >> I'm not competent enough to tell if it is better to have the same contract with members and non-members, maybe someone from RIPE NCC can answer that. > >> I think that they should be isolated because they should be used for different things. PA for networks with single upstream - they should receive ALLOCATED-BY-LIR from LIR's PA. PI for customers with the second upstream. On the other hand we all know that PI is used as small PA, without editing RIPE DB, of course. > > There is not anymore an obligation, for many years, to have multihoming. So, no difference here. Sure it is not an obligation, it is just my understanding what is meant by current policy or what it should mean. >> By removing PI, you would had to allow non-members to receive PA or you would had to force every current PI holder to became LIR. I know that most of the new members are in RIPE just for IPv4, but in the distant IPv6 only future, what would be the result of such change? What would be the reason to be a member in such future? > > Yes, that's the idea, please see my slides. PI holders will need to become members, maybe the fee will get an increase (something on the line of a small one-time setup fee and later on a proportion of the cost of a /32 if you are getting only a /48, etc., but this is for the membership to decide). What we all win with that is a fairer cost distribution and also an easier way to make sure that the rules are followed and nobody tricks the rules using a PI as PA. Specially for the NCC is much simpler. Easy as a flat rate for every LIR. Actually this is the main problem problem for me. LIR should by the name work as local internet registry. This has been broken for IPv4 by IPv4 shortage. Not everyone should be forced to be a RIPE NCC member. I'm perfectly fine with 50 EUR fee for every /48 for those. Such organization which needs PI have no plans for assigning addresses to third parties, so why they should be LIR when they don't plan to act as one? This would make IPv6 addresses less accessible. It is like LIR saying: "Do you want to have your own addresses or more then I gave you? Go to the RIPE NCC and pay them 1400 EUR/y! No matter what you do...". Those PI users would either loose protection of their own space or they would had to pay 28x more per year plus 2000 EUR sign up fee. What would do company outside of the internet business? They would not implement IPv6, that is easy! :-) >> In my opinion PI should still be here, but only for a special cases, non-ISP non-LIR organizations. So if there will be any use of PI space by ISP for its clients, it should be immediately reclaimed by RIPE NCC. Also LIR should not be entitled to claim PI for itself. But this is just my point of view. > > So then, again, let's roll back 2016-04, because is non-sense that somebody instead of using the addressing space for their own organization as end-user, is using it for a hotspot or datacenter. 2016-04 is not the problem, it doesn't say that you can use PI as PA. It just allows you to use your PI range on your premise and give access to such network to the third party. It does not allow you to give whole range to CPE. > I'm more and more convinced as we exchange emails on this, that either we clarify very well what is a sub-assignment (and if you follow the last couple of emails on that discussion you will see how difficult may be to clarify that with a "short" text), or we just put all in the same "class" of addressing space. Actually I don't think so. I still thinks that PI should stay PI, but it should be checked more thoroughly to whom it is given. >> Sincerely, >> Martin > > Dne st?eda 16. kv?tna 2018 16:10:13 CEST, JORDI PALET MARTINEZ via address-policy-wg napsal(a): > > Hi Martin, > > > > I'm clear about the IPv4 situation. No discussion on that. > > > > I also understand that both (ISP for special infrastructure and also large non-ISP) need addressing space. Call it PI or PA is another question. > > > > Having a single contract doesn't goes against the need for both kind of organizations. > > > > I think we both agree. What I'm saying is that there is no need to have both into different policies if are able to simplify for both organizations to have a single contract and a single policy (with of course, require a small different justification mechanism - or may be not even to make it much simpler). > > > > Can you tell me why you believe we need to keep them *isolated* ? I mean specific needs that makes impossible to accommodate both into a single policy? > > > > The only *real* difference in the policy is that one starts with /48 per end-site, the other with /32. Anything else? > > > > Regards, > > Jordi > > > > > > > > ?-----Mensaje original----- > > De: address-policy-wg en nombre de Martin Hun?k > > Fecha: mi?rcoles, 16 de mayo de 2018, 16:01 > > Para: , JORDI PALET MARTINEZ > > Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI > > > > Hi Jordi, > > > > I must say that I'm strongly against this proposal. > > > > Reasons: > > - Situation between IPv4 and IPv6 is quite different - reasons for canceling IPv4 PI was simply not enough space > > - Not everyone in the business had to be a LIR and some large non ISP organization could be legitimate user of PI space > > - Insufficient checks and under-educated LIRs doesn't necessary mean that concept of PI space is bad, only that it is misused > > > > Now some details. Even in IPv4 there is still PI space left, not for the ordinary networks, but for the IXPs. It is a fact that there are missuses of IPv6 PI space like ISP running in PI space. But if we want to cast the blame, it would come to the uneducated LIR operators and partially to the RIPE NCC because it did not educate them well (or at least explain when to ask for PI in the LIR portal). > > > > Personally, I had to ask my formal upstream (before we became LIR) specifically to make ALLOCATED-BY-LIR object and to make me mnt-lower, step by step because they didn't know how to do that. For such LIR it is easier to ask for PI just because they use to do that for the IPv4. > > > > There are also some large companies that would be legitimate to use current PI space. Not every organization had to be in internet business, so it should not be a LIR at all. Current concept of every major end-user to be a LIR is broken because need of IPv4, lets not spoil the IPv6 world the same way. > > > > Current PI space misuse could have been solved by more in depth checks. Like if the end user is an ISP, it is most likely misuse. Also if someone asks for PI, RIPE NCC should either pick up the phone or write an e-mail and ask LIR why they want to ask for PI. > > > > Can RIPE NCC make video about proper way how to make allocations for LIR's "downstream"/client? Maybe place it in PI assignment wizard in LIR portal. > > > > IPv4 shortage just broke the model LIR. Today just too much end users became a LIRs just to be given IPv4 space, but they would never serve as a local internet registry or would not know how to work as LIR. Canceling the IPv6 PI would not help to solve this problem, it would make it even worse, by pushing more and more end users to became LIR when they are actually not one. > > > > Best regards > > Martin > > > > Dne st?eda 16. kv?tna 2018 14:52:57 CEST, JORDI PALET MARTINEZ via address-policy-wg napsal(a): > > > Hi all, > > > > > > For those that haven't been in the meeting, the slides are available at https://ripe76.ripe.net/presentations/97-RIPE-2018-05-v1.pdf > > > > > > I believe we have several problems that my proposal is trying to fix. > > > > > > 1) See my previous email on the clarification of IPv6 PI sub-assignments. Is not just a matter of IPv6, but also IPv4. This is an alternative solution (at least of the IPv6 part - we could do the same for IPv4 of course and also remove IPv4 PI). > > > > > > 2) It was clear in the meeting, as we *all* know, that many folks in the community (and not only in this region) are abusing the policy and they actually use end-user space (PI policies) to *assign* (call it sub-assign if you prefer it), to third parties. > > > > > > 3) It may be the case that this happens because the fee structure. An LIR, currently, pays 1.400 Euros per year (plus one-time setup-fee of 2.000 Euros). And end-user just pay 50 Euros per resource assignment. So, it makes sense to just pay for 50 Euros, and then you may be providing services using NAT+CGN (in the case of IPv4) or a single /64 to each subscriber in the case of IPv6. It is broken, of course, but people do that. > > > > > > 4) The fee scheme is somehow responsible of that as well, as there is in my opinion, unfairness. A big ISP having an IPv6 /20, or /24 or /29 or /32 is paying always the same. This is the only region that have a "flat" rate. > > > > > > 5) We could fix the point above, auditing every end-user. But we could also fix it in a better way by: > > > a) A policy change in the line the one I've proposed (see the slides and the links for a diff) > > > b) Having a single LIR contract, instead of LIR and end-user > > > c) This may be (as an option), also become a way to make a price scheme which is proportional to the amount of resources allocated. > > > > > > Note that we don't need to change the fee scheme, but it is an opportunity for taking a look into that. It may be perfectly possible to keep the cost of end-users as 50 Euros (for a single /48, for example), but having a single contract. I know perfectly that fees are not "policy", however only if we address that we can do correctly the policy. A demonstration of that: When I proposed the IPv6 PI and it reached consensus, it was needed to create the "end-user" contract and the corresponding fee, so is something that we have done before. > > > > > > I know that the proposed text may be very imperfect, for example the usage of "ISPs", but this is not the key now, there are for sure several alternatives to that. For example, we could just differentiate both cases with "LIR that do subsequent distributions initially qualify for /32 up to /29 etc. LIRs that do not do subsequent distributions initially qualify for a /48 for each end-site". So please, don't consider specific text at this point of the discussion. > > > > > > And last, but not least, repeating myself, we could do this just for IPv6, or also work in parallel in a policy proposal for IPv4 PI removal as well. This will be probably the best choice, so we can let the NCC to have a simplified policy, a single contract and consequently less overhead: Simplification for everyone. > > > > > > Thoughts? > > > > > > > > > Regards, > > > Jordi > > > > > > > > > > > > > > > > > > ********************************************** > > > IPv4 is over > > > Are you ready for the new Internet ? > > > http://www.consulintel.es > > > The IPv6 Company > > > > > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.consulintel.es > > The IPv6 Company > > > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > > > > > > > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From apwg at c4inet.net Wed May 16 18:29:32 2018 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Wed, 16 May 2018 17:29:32 +0100 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> Message-ID: <20180516162932.GK17209@cilantro.c4inet.net> All, rather than making policy successively more dense, technically prescriptive and complicated, is it not way past time to abolish the PA/PI distinction altogether? In other words, decouple the "LIR" function from the "ISP" function. rgds, Sascha Luck On Wed, May 16, 2018 at 02:52:57PM +0200, JORDI PALET MARTINEZ via address-policy-wg wrote: >Hi all, > >For those that haven't been in the meeting, the slides are available at https://ripe76.ripe.net/presentations/97-RIPE-2018-05-v1.pdf > >I believe we have several problems that my proposal is trying to fix. > >1) See my previous email on the clarification of IPv6 PI sub-assignments. Is not just a matter of IPv6, but also IPv4. This is an alternative solution (at least of the IPv6 part - we could do the same for IPv4 of course and also remove IPv4 PI). > >2) It was clear in the meeting, as we *all* know, that many folks in the community (and not only in this region) are abusing the policy and they actually use end-user space (PI policies) to *assign* (call it sub-assign if you prefer it), to third parties. > >3) It may be the case that this happens because the fee structure. An LIR, currently, pays 1.400 Euros per year (plus one-time setup-fee of 2.000 Euros). And end-user just pay 50 Euros per resource assignment. So, it makes sense to just pay for 50 Euros, and then you may be providing services using NAT+CGN (in the case of IPv4) or a single /64 to each subscriber in the case of IPv6. It is broken, of course, but people do that. > >4) The fee scheme is somehow responsible of that as well, as there is in my opinion, unfairness. A big ISP having an IPv6 /20, or /24 or /29 or /32 is paying always the same. This is the only region that have a "flat" rate. > >5) We could fix the point above, auditing every end-user. But we could also fix it in a better way by: > a) A policy change in the line the one I've proposed (see the slides and the links for a diff) > b) Having a single LIR contract, instead of LIR and end-user > c) This may be (as an option), also become a way to make a price scheme which is proportional to the amount of resources allocated. > >Note that we don't need to change the fee scheme, but it is an opportunity for taking a look into that. It may be perfectly possible to keep the cost of end-users as 50 Euros (for a single /48, for example), but having a single contract. I know perfectly that fees are not "policy", however only if we address that we can do correctly the policy. A demonstration of that: When I proposed the IPv6 PI and it reached consensus, it was needed to create the "end-user" contract and the corresponding fee, so is something that we have done before. > >I know that the proposed text may be very imperfect, for example the usage of "ISPs", but this is not the key now, there are for sure several alternatives to that. For example, we could just differentiate both cases with "LIR that do subsequent distributions initially qualify for /32 up to /29 etc. LIRs that do not do subsequent distributions initially qualify for a /48 for each end-site". So please, don't consider specific text at this point of the discussion. > >And last, but not least, repeating myself, we could do this just for IPv6, or also work in parallel in a policy proposal for IPv4 PI removal as well. This will be probably the best choice, so we can let the NCC to have a simplified policy, a single contract and consequently less overhead: Simplification for everyone. > >Thoughts? > > >Regards, >Jordi > > > > > >********************************************** >IPv4 is over >Are you ready for the new Internet ? >http://www.consulintel.es >The IPv6 Company > >This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > From gert at space.net Wed May 16 18:35:32 2018 From: gert at space.net (Gert Doering) Date: Wed, 16 May 2018 18:35:32 +0200 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: <20180516162932.GK17209@cilantro.c4inet.net> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> <20180516162932.GK17209@cilantro.c4inet.net> Message-ID: <20180516163532.GF89741@Space.Net> Hi, On Wed, May 16, 2018 at 05:29:32PM +0100, Sascha Luck [ml] wrote: > rather than making policy successively more dense, technically > prescriptive and complicated, is it not way past time to abolish > the PA/PI distinction altogether? > In other words, decouple the "LIR" function from the "ISP" > function. Well, that seems to be what Jordi's idea seems to be about - but it is neither easy nor straightforward how to get there. We've tried a few years ago, and when you mix in "fees", "membership / voting rights" and "allocation size", things get amazingly complicated... (And if you are *not* looking at these aspects, removing the PA/PI label isn't actually achieving much, except replacing it by a "block for member" vs. "block for non-member" label, no?) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From apwg at c4inet.net Wed May 16 18:55:22 2018 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Wed, 16 May 2018 17:55:22 +0100 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: <20180516163532.GF89741@Space.Net> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> <20180516162932.GK17209@cilantro.c4inet.net> <20180516163532.GF89741@Space.Net> Message-ID: <20180516165522.GL17209@cilantro.c4inet.net> Hi Gert, On Wed, May 16, 2018 at 06:35:32PM +0200, Gert Doering wrote: >> In other words, decouple the "LIR" function from the "ISP" >> function. > >Well, that seems to be what Jordi's idea seems to be about - but it >is neither easy nor straightforward how to get there. We've tried >a few years ago, and when you mix in "fees", "membership / voting rights" >and "allocation size", things get amazingly complicated... I think it would actually simplify a lot of those issues. It doesn't remove the RIR->LIR->End User hierarchy but it removes the requirement that a LIR provide connectivity to an End User. (Basically, every LIR becomes a "sponsoring LIR") This removes the need for ISPs or hosters to be LIRs where they neither want to nor have the necessary skills or the time. The outcome would most likely be a lot fewer LIRs with a lot higher fees but they can of course recoup these via fees to their end users. The only negative I can see is deaggregation of IPv6 space but I think that particular boat sailed a long time ago... rgds, Sascha Luck > >(And if you are *not* looking at these aspects, removing the PA/PI >label isn't actually achieving much, except replacing it by a "block >for member" vs. "block for non-member" label, no?) > >Gert Doering > -- APWG chair >-- >have you enabled IPv6 on something today...? > >SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer >Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann >D-80807 Muenchen HRB: 136055 (AG Muenchen) >Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From president at ukraine.su Wed May 16 19:23:15 2018 From: president at ukraine.su (Max Tulyev) Date: Wed, 16 May 2018 20:23:15 +0300 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> Message-ID: <79a27f4a-90d8-1482-7a8d-b931a5baa2ec@ukraine.su> Wrote a huge post. Tried to remove all the impolite phrases from it then. Didn't manage to do that. Removed the whole post. So, in one sentence, I am against this. 16.05.18 15:52, JORDI PALET MARTINEZ via address-policy-wg ????: > Hi all, > > For those that haven't been in the meeting, the slides are available at https://ripe76.ripe.net/presentations/97-RIPE-2018-05-v1.pdf > > I believe we have several problems that my proposal is trying to fix. > > 1) See my previous email on the clarification of IPv6 PI sub-assignments. Is not just a matter of IPv6, but also IPv4. This is an alternative solution (at least of the IPv6 part - we could do the same for IPv4 of course and also remove IPv4 PI). > > 2) It was clear in the meeting, as we *all* know, that many folks in the community (and not only in this region) are abusing the policy and they actually use end-user space (PI policies) to *assign* (call it sub-assign if you prefer it), to third parties. > > 3) It may be the case that this happens because the fee structure. An LIR, currently, pays 1.400 Euros per year (plus one-time setup-fee of 2.000 Euros). And end-user just pay 50 Euros per resource assignment. So, it makes sense to just pay for 50 Euros, and then you may be providing services using NAT+CGN (in the case of IPv4) or a single /64 to each subscriber in the case of IPv6. It is broken, of course, but people do that. > > 4) The fee scheme is somehow responsible of that as well, as there is in my opinion, unfairness. A big ISP having an IPv6 /20, or /24 or /29 or /32 is paying always the same. This is the only region that have a "flat" rate. > > 5) We could fix the point above, auditing every end-user. But we could also fix it in a better way by: > a) A policy change in the line the one I've proposed (see the slides and the links for a diff) > b) Having a single LIR contract, instead of LIR and end-user > c) This may be (as an option), also become a way to make a price scheme which is proportional to the amount of resources allocated. > > Note that we don't need to change the fee scheme, but it is an opportunity for taking a look into that. It may be perfectly possible to keep the cost of end-users as 50 Euros (for a single /48, for example), but having a single contract. I know perfectly that fees are not "policy", however only if we address that we can do correctly the policy. A demonstration of that: When I proposed the IPv6 PI and it reached consensus, it was needed to create the "end-user" contract and the corresponding fee, so is something that we have done before. > > I know that the proposed text may be very imperfect, for example the usage of "ISPs", but this is not the key now, there are for sure several alternatives to that. For example, we could just differentiate both cases with "LIR that do subsequent distributions initially qualify for /32 up to /29 etc. LIRs that do not do subsequent distributions initially qualify for a /48 for each end-site". So please, don't consider specific text at this point of the discussion. > > And last, but not least, repeating myself, we could do this just for IPv6, or also work in parallel in a policy proposal for IPv4 PI removal as well. This will be probably the best choice, so we can let the NCC to have a simplified policy, a single contract and consequently less overhead: Simplification for everyone. > > Thoughts? > > > Regards, > Jordi > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > > From jordi.palet at consulintel.es Wed May 16 19:25:27 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 16 May 2018 19:25:27 +0200 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: <20180516165522.GL17209@cilantro.c4inet.net> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> <20180516162932.GK17209@cilantro.c4inet.net> <20180516163532.GF89741@Space.Net> <20180516165522.GL17209@cilantro.c4inet.net> Message-ID: I don't see why this would mean "lower" number of LIRs? Actually, I think will be the contrary. I think most of the end-users will become LIRs, especially if the AGM makes a smart move about how to attract them (fee scheme, contract, etc.). I don't see also why this would create more disaggregation. The actual end-users will become LIRs. The actual LIRs will remain as LIRs. Both of them will announce the same addressing space. In summary: Who needs to have stable addresses and avoid renumbering if changing ISP or data center, or whatever, will be an LIRs. What I'm missing from your rationale for having those opinions? There are many ways to do that regarding the fees, for example: 1) Fee depending on the "size" of the allocation (categories, as it was some years ago) 2) Single fee for all 3) 2 fees categories (those receiving more than /32 and those receiving less than that) 4) etc. I think we need to recall that we have been already under 1, and that 4 out of 5 RIRs are still there. So I don't really think is an issue at all. Regards, Jordi ?-----Mensaje original----- De: address-policy-wg en nombre de "Sascha Luck [ml]" Fecha: mi?rcoles, 16 de mayo de 2018, 18:55 Para: Gert Doering CC: Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI Hi Gert, On Wed, May 16, 2018 at 06:35:32PM +0200, Gert Doering wrote: >> In other words, decouple the "LIR" function from the "ISP" >> function. > >Well, that seems to be what Jordi's idea seems to be about - but it >is neither easy nor straightforward how to get there. We've tried >a few years ago, and when you mix in "fees", "membership / voting rights" >and "allocation size", things get amazingly complicated... I think it would actually simplify a lot of those issues. It doesn't remove the RIR->LIR->End User hierarchy but it removes the requirement that a LIR provide connectivity to an End User. (Basically, every LIR becomes a "sponsoring LIR") This removes the need for ISPs or hosters to be LIRs where they neither want to nor have the necessary skills or the time. The outcome would most likely be a lot fewer LIRs with a lot higher fees but they can of course recoup these via fees to their end users. The only negative I can see is deaggregation of IPv6 space but I think that particular boat sailed a long time ago... rgds, Sascha Luck > >(And if you are *not* looking at these aspects, removing the PA/PI >label isn't actually achieving much, except replacing it by a "block >for member" vs. "block for non-member" label, no?) > >Gert Doering > -- APWG chair >-- >have you enabled IPv6 on something today...? > >SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer >Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann >D-80807 Muenchen HRB: 136055 (AG Muenchen) >Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From jordi.palet at consulintel.es Wed May 16 19:28:08 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 16 May 2018 19:28:08 +0200 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: <79a27f4a-90d8-1482-7a8d-b931a5baa2ec@ukraine.su> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> <79a27f4a-90d8-1482-7a8d-b931a5baa2ec@ukraine.su> Message-ID: <0A19F922-CF6C-43C5-B034-78CAA929EDBB@consulintel.es> Hi Max, I will not have any problem if you need to write something unpolite just to explain much better what is your view. What I will not help in any discussion is just responding "I'm for" or "I'm against" without further explanations. Otherwise, feel free to talk to me at any time during the rest of the week. Regards, Jordi ?-----Mensaje original----- De: address-policy-wg en nombre de Max Tulyev Fecha: mi?rcoles, 16 de mayo de 2018, 19:22 Para: Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI Wrote a huge post. Tried to remove all the impolite phrases from it then. Didn't manage to do that. Removed the whole post. So, in one sentence, I am against this. 16.05.18 15:52, JORDI PALET MARTINEZ via address-policy-wg ????: > Hi all, > > For those that haven't been in the meeting, the slides are available at https://ripe76.ripe.net/presentations/97-RIPE-2018-05-v1.pdf > > I believe we have several problems that my proposal is trying to fix. > > 1) See my previous email on the clarification of IPv6 PI sub-assignments. Is not just a matter of IPv6, but also IPv4. This is an alternative solution (at least of the IPv6 part - we could do the same for IPv4 of course and also remove IPv4 PI). > > 2) It was clear in the meeting, as we *all* know, that many folks in the community (and not only in this region) are abusing the policy and they actually use end-user space (PI policies) to *assign* (call it sub-assign if you prefer it), to third parties. > > 3) It may be the case that this happens because the fee structure. An LIR, currently, pays 1.400 Euros per year (plus one-time setup-fee of 2.000 Euros). And end-user just pay 50 Euros per resource assignment. So, it makes sense to just pay for 50 Euros, and then you may be providing services using NAT+CGN (in the case of IPv4) or a single /64 to each subscriber in the case of IPv6. It is broken, of course, but people do that. > > 4) The fee scheme is somehow responsible of that as well, as there is in my opinion, unfairness. A big ISP having an IPv6 /20, or /24 or /29 or /32 is paying always the same. This is the only region that have a "flat" rate. > > 5) We could fix the point above, auditing every end-user. But we could also fix it in a better way by: > a) A policy change in the line the one I've proposed (see the slides and the links for a diff) > b) Having a single LIR contract, instead of LIR and end-user > c) This may be (as an option), also become a way to make a price scheme which is proportional to the amount of resources allocated. > > Note that we don't need to change the fee scheme, but it is an opportunity for taking a look into that. It may be perfectly possible to keep the cost of end-users as 50 Euros (for a single /48, for example), but having a single contract. I know perfectly that fees are not "policy", however only if we address that we can do correctly the policy. A demonstration of that: When I proposed the IPv6 PI and it reached consensus, it was needed to create the "end-user" contract and the corresponding fee, so is something that we have done before. > > I know that the proposed text may be very imperfect, for example the usage of "ISPs", but this is not the key now, there are for sure several alternatives to that. For example, we could just differentiate both cases with "LIR that do subsequent distributions initially qualify for /32 up to /29 etc. LIRs that do not do subsequent distributions initially qualify for a /48 for each end-site". So please, don't consider specific text at this point of the discussion. > > And last, but not least, repeating myself, we could do this just for IPv6, or also work in parallel in a policy proposal for IPv4 PI removal as well. This will be probably the best choice, so we can let the NCC to have a simplified policy, a single contract and consequently less overhead: Simplification for everyone. > > Thoughts? > > > Regards, > Jordi > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From jordi.palet at consulintel.es Wed May 16 19:37:05 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 16 May 2018 19:37:05 +0200 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: <2182481.LFyoZQ4taB@rumburak.ite.tul.cz> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> <2116215.Frit7E0hTN@rumburak.ite.tul.cz> <147471F6-091C-4E3D-879A-8089C70DD140@consulintel.es> <2182481.LFyoZQ4taB@rumburak.ite.tul.cz> Message-ID: <4FF305D7-C93E-40CE-8E3B-88ABC8B60621@consulintel.es> Responding below, in-line. Regards, Jordi ?-----Mensaje original----- De: address-policy-wg en nombre de Martin Hun?k Fecha: mi?rcoles, 16 de mayo de 2018, 18:29 Para: , JORDI PALET MARTINEZ Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI in-line Regards, Martin Dne st?eda 16. kv?tna 2018 17:45:01 CEST, JORDI PALET MARTINEZ via address-policy-wg napsal(a): > Below, in-line. > > Regards, > Jordi > > > > ?-----Mensaje original----- > De: address-policy-wg en nombre de Martin Hun?k > Fecha: mi?rcoles, 16 de mayo de 2018, 17:28 > Para: , JORDI PALET MARTINEZ > Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI > >> Hi Jordi, > >> As I understand it, the PA is only for a LIR and PI is also for sponsored organization. Also the PI is solely for the end user infrastructure and and PA can be further allocated or assigned. > > This is our actual definition. We can change it whenever we want. What I'm asking is what is the *real* distinction among them. Forget for a minute in contracts, fee structure and so on. There is no need to call the same with different names if we don't want. I'm calling here for simplicity. Once we remove the sub-assignment obstacle, there is not anymore a difference. Discussion should be about, if we want to / should remove such *obstacle*. I would personally prefer that policy about PI space would stay the same. Just RIPE NCC should be more investigative and restrictive when assigning those. Being Internet policy is very difficult. If we have ways to avoid that, is an easier way to achieve the same. Policies are for a fair distribution of the resources, to make that distribution simpler, not to have complex policies and then being unable to track how well anyone is behaving with them. >> I'm not competent enough to tell if it is better to have the same contract with members and non-members, maybe someone from RIPE NCC can answer that. > >> I think that they should be isolated because they should be used for different things. PA for networks with single upstream - they should receive ALLOCATED-BY-LIR from LIR's PA. PI for customers with the second upstream. On the other hand we all know that PI is used as small PA, without editing RIPE DB, of course. > > There is not anymore an obligation, for many years, to have multihoming. So, no difference here. Sure it is not an obligation, it is just my understanding what is meant by current policy or what it should mean. >> By removing PI, you would had to allow non-members to receive PA or you would had to force every current PI holder to became LIR. I know that most of the new members are in RIPE just for IPv4, but in the distant IPv6 only future, what would be the result of such change? What would be the reason to be a member in such future? > > Yes, that's the idea, please see my slides. PI holders will need to become members, maybe the fee will get an increase (something on the line of a small one-time setup fee and later on a proportion of the cost of a /32 if you are getting only a /48, etc., but this is for the membership to decide). What we all win with that is a fairer cost distribution and also an easier way to make sure that the rules are followed and nobody tricks the rules using a PI as PA. Specially for the NCC is much simpler. Easy as a flat rate for every LIR. Actually this is the main problem problem for me. LIR should by the name work as local internet registry. This has been broken for IPv4 by IPv4 shortage. Not everyone should be forced to be a RIPE NCC member. I'm perfectly fine with 50 EUR fee for every /48 for those. Such organization which needs PI have no plans for assigning Is easier, but it is fair? addresses to third parties, so why they should be LIR when they don't plan to act as one? The problem is that once we accepted 2016-04, that got broken. End-users being assigned a /48 are using that now to sub-assign addresses to other end-users (employees, students, users of a hot-spot, etc.). This would make IPv6 addresses less accessible. It is like LIR saying: "Do you want to have your own addresses or more then I gave you? Go to the RIPE NCC and pay them 1400 EUR/y! No matter what you do...". Those PI users would either loose protection of their own space or they would had to pay 28x more per year plus 2000 EUR sign up fee. What would do company outside of the internet business? They would not implement IPv6, that is easy! :-) As said before, this is fixed in combination with the fee structure decision by the AGM. So *no*, on the contrary, will be fairer. I think probably a 50 Euros cost for a /48 is really too low, and may be a /32 will become cheaper, and of course, a /20 more expensive. There are many possible models for that, but it can be perfectly managed to avoid anyone having a requirement from a /48 to not being able to afford it. >> In my opinion PI should still be here, but only for a special cases, non-ISP non-LIR organizations. So if there will be any use of PI space by ISP for its clients, it should be immediately reclaimed by RIPE NCC. Also LIR should not be entitled to claim PI for itself. But this is just my point of view. > > So then, again, let's roll back 2016-04, because is non-sense that somebody instead of using the addressing space for their own organization as end-user, is using it for a hotspot or datacenter. 2016-04 is not the problem, it doesn't say that you can use PI as PA. It just allows you to use your PI range on your premise and give access to such network to the third party. It does not allow you to give whole range to CPE. It allows sub-assigments, which was not the intent of the original IPv6 PI, at all. > I'm more and more convinced as we exchange emails on this, that either we clarify very well what is a sub-assignment (and if you follow the last couple of emails on that discussion you will see how difficult may be to clarify that with a "short" text), or we just put all in the same "class" of addressing space. Actually I don't think so. I still thinks that PI should stay PI, but it should be checked more thoroughly to whom it is given. >> Sincerely, >> Martin > > Dne st?eda 16. kv?tna 2018 16:10:13 CEST, JORDI PALET MARTINEZ via address-policy-wg napsal(a): > > Hi Martin, > > > > I'm clear about the IPv4 situation. No discussion on that. > > > > I also understand that both (ISP for special infrastructure and also large non-ISP) need addressing space. Call it PI or PA is another question. > > > > Having a single contract doesn't goes against the need for both kind of organizations. > > > > I think we both agree. What I'm saying is that there is no need to have both into different policies if are able to simplify for both organizations to have a single contract and a single policy (with of course, require a small different justification mechanism - or may be not even to make it much simpler). > > > > Can you tell me why you believe we need to keep them *isolated* ? I mean specific needs that makes impossible to accommodate both into a single policy? > > > > The only *real* difference in the policy is that one starts with /48 per end-site, the other with /32. Anything else? > > > > Regards, > > Jordi > > > > > > > > ?-----Mensaje original----- > > De: address-policy-wg en nombre de Martin Hun?k > > Fecha: mi?rcoles, 16 de mayo de 2018, 16:01 > > Para: , JORDI PALET MARTINEZ > > Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI > > > > Hi Jordi, > > > > I must say that I'm strongly against this proposal. > > > > Reasons: > > - Situation between IPv4 and IPv6 is quite different - reasons for canceling IPv4 PI was simply not enough space > > - Not everyone in the business had to be a LIR and some large non ISP organization could be legitimate user of PI space > > - Insufficient checks and under-educated LIRs doesn't necessary mean that concept of PI space is bad, only that it is misused > > > > Now some details. Even in IPv4 there is still PI space left, not for the ordinary networks, but for the IXPs. It is a fact that there are missuses of IPv6 PI space like ISP running in PI space. But if we want to cast the blame, it would come to the uneducated LIR operators and partially to the RIPE NCC because it did not educate them well (or at least explain when to ask for PI in the LIR portal). > > > > Personally, I had to ask my formal upstream (before we became LIR) specifically to make ALLOCATED-BY-LIR object and to make me mnt-lower, step by step because they didn't know how to do that. For such LIR it is easier to ask for PI just because they use to do that for the IPv4. > > > > There are also some large companies that would be legitimate to use current PI space. Not every organization had to be in internet business, so it should not be a LIR at all. Current concept of every major end-user to be a LIR is broken because need of IPv4, lets not spoil the IPv6 world the same way. > > > > Current PI space misuse could have been solved by more in depth checks. Like if the end user is an ISP, it is most likely misuse. Also if someone asks for PI, RIPE NCC should either pick up the phone or write an e-mail and ask LIR why they want to ask for PI. > > > > Can RIPE NCC make video about proper way how to make allocations for LIR's "downstream"/client? Maybe place it in PI assignment wizard in LIR portal. > > > > IPv4 shortage just broke the model LIR. Today just too much end users became a LIRs just to be given IPv4 space, but they would never serve as a local internet registry or would not know how to work as LIR. Canceling the IPv6 PI would not help to solve this problem, it would make it even worse, by pushing more and more end users to became LIR when they are actually not one. > > > > Best regards > > Martin > > > > Dne st?eda 16. kv?tna 2018 14:52:57 CEST, JORDI PALET MARTINEZ via address-policy-wg napsal(a): > > > Hi all, > > > > > > For those that haven't been in the meeting, the slides are available at https://ripe76.ripe.net/presentations/97-RIPE-2018-05-v1.pdf > > > > > > I believe we have several problems that my proposal is trying to fix. > > > > > > 1) See my previous email on the clarification of IPv6 PI sub-assignments. Is not just a matter of IPv6, but also IPv4. This is an alternative solution (at least of the IPv6 part - we could do the same for IPv4 of course and also remove IPv4 PI). > > > > > > 2) It was clear in the meeting, as we *all* know, that many folks in the community (and not only in this region) are abusing the policy and they actually use end-user space (PI policies) to *assign* (call it sub-assign if you prefer it), to third parties. > > > > > > 3) It may be the case that this happens because the fee structure. An LIR, currently, pays 1.400 Euros per year (plus one-time setup-fee of 2.000 Euros). And end-user just pay 50 Euros per resource assignment. So, it makes sense to just pay for 50 Euros, and then you may be providing services using NAT+CGN (in the case of IPv4) or a single /64 to each subscriber in the case of IPv6. It is broken, of course, but people do that. > > > > > > 4) The fee scheme is somehow responsible of that as well, as there is in my opinion, unfairness. A big ISP having an IPv6 /20, or /24 or /29 or /32 is paying always the same. This is the only region that have a "flat" rate. > > > > > > 5) We could fix the point above, auditing every end-user. But we could also fix it in a better way by: > > > a) A policy change in the line the one I've proposed (see the slides and the links for a diff) > > > b) Having a single LIR contract, instead of LIR and end-user > > > c) This may be (as an option), also become a way to make a price scheme which is proportional to the amount of resources allocated. > > > > > > Note that we don't need to change the fee scheme, but it is an opportunity for taking a look into that. It may be perfectly possible to keep the cost of end-users as 50 Euros (for a single /48, for example), but having a single contract. I know perfectly that fees are not "policy", however only if we address that we can do correctly the policy. A demonstration of that: When I proposed the IPv6 PI and it reached consensus, it was needed to create the "end-user" contract and the corresponding fee, so is something that we have done before. > > > > > > I know that the proposed text may be very imperfect, for example the usage of "ISPs", but this is not the key now, there are for sure several alternatives to that. For example, we could just differentiate both cases with "LIR that do subsequent distributions initially qualify for /32 up to /29 etc. LIRs that do not do subsequent distributions initially qualify for a /48 for each end-site". So please, don't consider specific text at this point of the discussion. > > > > > > And last, but not least, repeating myself, we could do this just for IPv6, or also work in parallel in a policy proposal for IPv4 PI removal as well. This will be probably the best choice, so we can let the NCC to have a simplified policy, a single contract and consequently less overhead: Simplification for everyone. > > > > > > Thoughts? > > > > > > > > > Regards, > > > Jordi > > > > > > > > > > > > > > > > > > ********************************************** > > > IPv4 is over > > > Are you ready for the new Internet ? > > > http://www.consulintel.es > > > The IPv6 Company > > > > > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.consulintel.es > > The IPv6 Company > > > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > > > > > > > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From wusel+ml at uu.org Wed May 16 20:37:10 2018 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Wed, 16 May 2018 20:37:10 +0200 Subject: [address-policy-wg] 2018-02 Assignment Clarification in IPv6 Policy - comments from today meeting In-Reply-To: <38E24466-EDEB-4B44-897C-FD565DCC1AC2@consulintel.es> References: <53c22ca9-dce4-6782-61bf-9a0644a580c7@uu.org> <38E24466-EDEB-4B44-897C-FD565DCC1AC2@consulintel.es> Message-ID: <7817b7d1-39ba-5067-8fc4-cadbda9ef0ac@uu.org> Hi there, on 16.05.2018 17:33, JORDI PALET MARTINEZ via address-policy-wg wrote: > So, to make sure I understood your point. You think that a single /128 prefix is ok to be sub-assigned (as per the current policy), but a single /64 prefix is not? > Or you will agree in a change that only fix that? I think that the current text serves it's purpose and _can_ be understood in the way it was intended to (i. e. countering the, non-standard, RIPE NCC idea that using SLAAC or DHCPv6 constitutes an act of sub-assigning addresses, forbidden as per section 2.6). If you read it while suffering from an overdose of technical writings, a normal reaction could be "R U kidding me? Addresses, even plural, but not prefixes ? does not compute". I do *not* agree that _that paragraph_ needs another band-aid. I think that rough consensus should be sought on what uses by the assignment holder of assigned IPv6 space are considered ok. Afterwards, amending the policy at least should be more easy ? if still considered necessary by then. > Regarding the specific wording, you're totally right and we should decide *if* there is a way to re-formulate it. I think we should keep it as it is, take a step back and consider what issue, if any, there is. Frankly, I do not see one ATM; policy texts should not try to micromanage the readers mind, IMO. > That's the reason I initially suggested, even when discussing 2016-04, that the text should be only in the IPv6 PI section ... the consensus was in the other direction. Well, the current policy does allow ?minor? third-party-usage for any (note the word) assigned IPv6 space. Previously, adopting RIPE NCCs view on SLAAC being an act of address assignment, no-one was allowed to run a Guest WiFi or similar with RIPE area assigned IPv6 space, PA or PI ? as sub-assignments were (and are) forbidden and providing a third party with single addresses out of an assignment holder's addresses constituted a sub-assignment according to RIPE NCC (this is now fixed per policy in ripe-699's section 2.6). So, if you agree with RIPE NCCs view, 2.6 is the correct location. If not, the policy maybe was fine and the issue lay elsewhere. > This is the big problem in my opinion, and I actually forgot the mention it before. I think policy must be as much as possible, a text which has only one interpretation, even if that means it is longer. Otherwise, and I explained this in emails when discussing 2016-04, people that "follows" the policy process has advantage in terms of interpretation vs a newcomer that will read only the *policy text*, but not the impact analysis, and all the discussions used to clarify the policy text. I totally disagree with you on this. The more words go into a policy, the more loopholes are opened, which then have to backfill with new wordings, leading to pages after pages of policy text. A policy text should be easy to understand (especially for non-native speakers of the english language ;)), give a guideline on what use case it expects to cover and at all costs refrain from giving examples. The thing with examples is that, from my experience, they invite people to game the rules. Please don't overengineer the policies. Regards, -kai From wusel+ml at uu.org Wed May 16 22:06:24 2018 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Wed, 16 May 2018 22:06:24 +0200 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> Message-ID: <197841dd-a3ce-80d5-ef74-58501dc7876f@uu.org> Am 16.05.2018 um 14:52 schrieb JORDI PALET MARTINEZ via address-policy-wg: > [?] > I believe we have several problems that my proposal is trying to fix. > [?] > Thoughts? To put it in a nutshell, I think you throw out the baby with bath water here: you're not simply "merging the requirements for PI and PA in a single policy", you'd take away any means for a non-LIR to request non-PA IP space. Moreover, you intend to force any current IPv6 PI holder into either becoming an LIR (which amounts to a 28fold cost increase: 50 => 1400 EUR/year) or to abandon the PIv6 space they build there infrastructure on. I don't yet understand what's your agenda, but I'm deeply concerned. Anyway: I oppose this proposal. It would cause a lot harm for no obvious reason. -kai From wusel+ml at uu.org Wed May 16 23:03:56 2018 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Wed, 16 May 2018 23:03:56 +0200 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: <20180516165522.GL17209@cilantro.c4inet.net> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> <20180516162932.GK17209@cilantro.c4inet.net> <20180516163532.GF89741@Space.Net> <20180516165522.GL17209@cilantro.c4inet.net> Message-ID: <85f1a3d7-68a6-6851-885b-8f96285d7389@uu.org> Moin, am 16.05.2018 um 18:55 schrieb Sascha Luck [ml]: > This removes the need for ISPs or hosters to be LIRs where they > neither want to nor have the necessary skills or the time. > > The outcome would most likely be a lot fewer LIRs with a lot > higher fees but they can of course recoup these via fees to their > end users. If there would be only v6, I'd agree, but given that v4 refuses to die, IPv6 is a far lesser incentive to become an LIR compared to the /22 shot of IPv4. I don't expect the number of LIRs in the RIPE area to come down for the next few years. When the past-last-/8 pool has finally dried up, plus 2 years (holding time), well, yes, maybe. > > The only negative I can see is deaggregation of IPv6 space but I > think that particular boat sailed a long time ago... I certainly feels that way. Regards, -kai From leo.vegoda at icann.org Thu May 17 02:17:43 2018 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 17 May 2018 00:17:43 +0000 Subject: [address-policy-wg] [Ext] Re: proposal to remove IPv6 PI In-Reply-To: <20180516165522.GL17209@cilantro.c4inet.net> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> <20180516162932.GK17209@cilantro.c4inet.net> <20180516163532.GF89741@Space.Net> <20180516165522.GL17209@cilantro.c4inet.net> Message-ID: Sascha Luck [ml] wrote: [...] > I think it would actually simplify a lot of those issues. > It doesn't remove the RIR->LIR->End User hierarchy > but it removes the requirement that a LIR provide > connectivity to an End User. Since when has this been a requirement? Section 2.4 of ripe-699 defines LIRs and describes them as "primarily" providing addresses for network services that they provide. Have I misunderstood the policy, or is there currently a requirement that LIR provide network connectivity to the users of the addresses they assign or sub-allocate? Kind regards, Leo Vegoda -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3739 bytes Desc: not available URL: From jordi.palet at consulintel.es Thu May 17 07:50:17 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 17 May 2018 07:50:17 +0200 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: <197841dd-a3ce-80d5-ef74-58501dc7876f@uu.org> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> <197841dd-a3ce-80d5-ef74-58501dc7876f@uu.org> Message-ID: <12F2ECA0-5306-4ECC-848F-B2514096EB8C@consulintel.es> PI and PA are artificial names for the same thing. There is only one type of Global Unicast Addresses in IPv6. As I already explained before, the same way the AGM created the end-user contract and the corresponding fee, they should be a new fee structure within the LIR contract, for those that have one of few /48s instead of /32 or /29, etc. Regards, Jordi ?-----Mensaje original----- De: address-policy-wg en nombre de Kai 'wusel' Siering Organizaci?n: Unseen University, Department of Magic Mails Fecha: mi?rcoles, 16 de mayo de 2018, 22:06 Para: Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI Am 16.05.2018 um 14:52 schrieb JORDI PALET MARTINEZ via address-policy-wg: > [?] > I believe we have several problems that my proposal is trying to fix. > [?] > Thoughts? To put it in a nutshell, I think you throw out the baby with bath water here: you're not simply "merging the requirements for PI and PA in a single policy", you'd take away any means for a non-LIR to request non-PA IP space. Moreover, you intend to force any current IPv6 PI holder into either becoming an LIR (which amounts to a 28fold cost increase: 50 => 1400 EUR/year) or to abandon the PIv6 space they build there infrastructure on. I don't yet understand what's your agenda, but I'm deeply concerned. Anyway: I oppose this proposal. It would cause a lot harm for no obvious reason. -kai ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From maxtul at netassist.ua Wed May 16 19:02:52 2018 From: maxtul at netassist.ua (Max Tulyev) Date: Wed, 16 May 2018 20:02:52 +0300 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> Message-ID: Wrote a huge post. Tried to remove all the impolite phrases from it then. Didn't manage to do that. Removed the whole post. So, in one sentence, I am against this. 16.05.18 15:52, JORDI PALET MARTINEZ via address-policy-wg ????: > Hi all, > > For those that haven't been in the meeting, the slides are available at https://ripe76.ripe.net/presentations/97-RIPE-2018-05-v1.pdf > > I believe we have several problems that my proposal is trying to fix. > > 1) See my previous email on the clarification of IPv6 PI sub-assignments. Is not just a matter of IPv6, but also IPv4. This is an alternative solution (at least of the IPv6 part - we could do the same for IPv4 of course and also remove IPv4 PI). > > 2) It was clear in the meeting, as we *all* know, that many folks in the community (and not only in this region) are abusing the policy and they actually use end-user space (PI policies) to *assign* (call it sub-assign if you prefer it), to third parties. > > 3) It may be the case that this happens because the fee structure. An LIR, currently, pays 1.400 Euros per year (plus one-time setup-fee of 2.000 Euros). And end-user just pay 50 Euros per resource assignment. So, it makes sense to just pay for 50 Euros, and then you may be providing services using NAT+CGN (in the case of IPv4) or a single /64 to each subscriber in the case of IPv6. It is broken, of course, but people do that. > > 4) The fee scheme is somehow responsible of that as well, as there is in my opinion, unfairness. A big ISP having an IPv6 /20, or /24 or /29 or /32 is paying always the same. This is the only region that have a "flat" rate. > > 5) We could fix the point above, auditing every end-user. But we could also fix it in a better way by: > a) A policy change in the line the one I've proposed (see the slides and the links for a diff) > b) Having a single LIR contract, instead of LIR and end-user > c) This may be (as an option), also become a way to make a price scheme which is proportional to the amount of resources allocated. > > Note that we don't need to change the fee scheme, but it is an opportunity for taking a look into that. It may be perfectly possible to keep the cost of end-users as 50 Euros (for a single /48, for example), but having a single contract. I know perfectly that fees are not "policy", however only if we address that we can do correctly the policy. A demonstration of that: When I proposed the IPv6 PI and it reached consensus, it was needed to create the "end-user" contract and the corresponding fee, so is something that we have done before. > > I know that the proposed text may be very imperfect, for example the usage of "ISPs", but this is not the key now, there are for sure several alternatives to that. For example, we could just differentiate both cases with "LIR that do subsequent distributions initially qualify for /32 up to /29 etc. LIRs that do not do subsequent distributions initially qualify for a /48 for each end-site". So please, don't consider specific text at this point of the discussion. > > And last, but not least, repeating myself, we could do this just for IPv6, or also work in parallel in a policy proposal for IPv4 PI removal as well. This will be probably the best choice, so we can let the NCC to have a simplified policy, a single contract and consequently less overhead: Simplification for everyone. > > Thoughts? > > > Regards, > Jordi > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > > From hph at oslo.net Thu May 17 10:35:12 2018 From: hph at oslo.net (Hans Petter Holen) Date: Thu, 17 May 2018 10:35:12 +0200 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> Message-ID: I think this is an interesting proposal which requires some through analysis. >From a pure policy point of view I do not think a distinction between PI and PA makes sense in a post-depletion world. Following this reasoning it does not make sense in v6 either. BUT I do understand the concern that this policy change may affect the membership fees, and I agree that this needs to be solved. The RIPE NCC is a membership organisation that needs to cover its costs from its membership. If policy is changed so that RIPE NCC gets 10x members the membership fee would have to be adjusted similarly. Another approach would be for the RIPE NCC to change its membership fee structure so the fee structure is policy-neutral. So it would be interesting to have a sense not only of support/not support but also support if negative financial effect can be mitigated. On Wed, 16 May 2018 at 14:54, JORDI PALET MARTINEZ via address-policy-wg < address-policy-wg at ripe.net> wrote: > Hi all, > > For those that haven't been in the meeting, the slides are available at > https://ripe76.ripe.net/presentations/97-RIPE-2018-05-v1.pdf > > I believe we have several problems that my proposal is trying to fix. > > 1) See my previous email on the clarification of IPv6 PI sub-assignments. > Is not just a matter of IPv6, but also IPv4. This is an alternative > solution (at least of the IPv6 part - we could do the same for IPv4 of > course and also remove IPv4 PI). > > 2) It was clear in the meeting, as we *all* know, that many folks in the > community (and not only in this region) are abusing the policy and they > actually use end-user space (PI policies) to *assign* (call it sub-assign > if you prefer it), to third parties. > > 3) It may be the case that this happens because the fee structure. An LIR, > currently, pays 1.400 Euros per year (plus one-time setup-fee of 2.000 > Euros). And end-user just pay 50 Euros per resource assignment. So, it > makes sense to just pay for 50 Euros, and then you may be providing > services using NAT+CGN (in the case of IPv4) or a single /64 to each > subscriber in the case of IPv6. It is broken, of course, but people do that. > > 4) The fee scheme is somehow responsible of that as well, as there is in > my opinion, unfairness. A big ISP having an IPv6 /20, or /24 or /29 or /32 > is paying always the same. This is the only region that have a "flat" rate. > > 5) We could fix the point above, auditing every end-user. But we could > also fix it in a better way by: > a) A policy change in the line the one I've proposed (see the > slides and the links for a diff) > b) Having a single LIR contract, instead of LIR and end-user > c) This may be (as an option), also become a way to make a price > scheme which is proportional to the amount of resources allocated. > > Note that we don't need to change the fee scheme, but it is an opportunity > for taking a look into that. It may be perfectly possible to keep the cost > of end-users as 50 Euros (for a single /48, for example), but having a > single contract. I know perfectly that fees are not "policy", however only > if we address that we can do correctly the policy. A demonstration of that: > When I proposed the IPv6 PI and it reached consensus, it was needed to > create the "end-user" contract and the corresponding fee, so is something > that we have done before. > > I know that the proposed text may be very imperfect, for example the usage > of "ISPs", but this is not the key now, there are for sure several > alternatives to that. For example, we could just differentiate both cases > with "LIR that do subsequent distributions initially qualify for /32 up to > /29 etc. LIRs that do not do subsequent distributions initially qualify for > a /48 for each end-site". So please, don't consider specific text at this > point of the discussion. > > And last, but not least, repeating myself, we could do this just for IPv6, > or also work in parallel in a policy proposal for IPv4 PI removal as well. > This will be probably the best choice, so we can let the NCC to have a > simplified policy, a single contract and consequently less overhead: > Simplification for everyone. > > Thoughts? > > > Regards, > Jordi > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > > > > > -- Sincerely, Hans Petter Holen - hph at oslo.net - +47 45066054 -------------- next part -------------- An HTML attachment was scrubbed... URL: From max at rfc2324.org Thu May 17 17:36:23 2018 From: max at rfc2324.org (Maximilian Wilhelm) Date: Thu, 17 May 2018 17:36:23 +0200 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: <4FF305D7-C93E-40CE-8E3B-88ABC8B60621@consulintel.es> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> <2116215.Frit7E0hTN@rumburak.ite.tul.cz> <147471F6-091C-4E3D-879A-8089C70DD140@consulintel.es> <2182481.LFyoZQ4taB@rumburak.ite.tul.cz> <4FF305D7-C93E-40CE-8E3B-88ABC8B60621@consulintel.es> Message-ID: <20180517153623.GE8542@principal.rfc2324.org> Anno domini 2018 JORDI PALET MARTINEZ via address-policy-wg scripsit: > Responding below, in-line. *PLEASE* use some meaningful way to quote and answer inline so a reader can distinguish between the original text and your answer. You current mode of answering is making this really hard. > > De: address-policy-wg en nombre de Martin Hun?k > > Fecha: mi?rcoles, 16 de mayo de 2018, 17:28 > > Para: , JORDI PALET MARTINEZ > > Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI > > > >> Hi Jordi, > > > >> As I understand it, the PA is only for a LIR and PI is also for sponsored organization. Also the PI is solely for the end user infrastructure and and PA can be further allocated or assigned. > > > > This is our actual definition. We can change it whenever we want. What I'm asking is what is the *real* distinction among them. Forget for a minute in contracts, fee structure and so on. There is no need to call the same with different names if we don't want. I'm calling here for simplicity. Once we remove the sub-assignment obstacle, there is not anymore a difference. > > Discussion should be about, if we want to / should remove such *obstacle*. I would personally prefer that policy about PI space would stay the same. Just RIPE NCC should be more investigative and restrictive when assigning those. > > Being Internet policy is very difficult. If we have ways to avoid that, is an easier way to achieve the same. Policies are for a fair distribution of the resources, to make that distribution simpler, not to have complex policies and then being unable to track how well anyone is behaving with them. > > > Yes, that's the idea, please see my slides. PI holders will need to become members, maybe the fee will get an increase (something on the line of a small one-time setup fee and later on a proportion of the cost of a /32 if you are getting only a /48, etc., but this is for the membership to decide). What we all win with that is a fairer cost distribution and also an easier way to make sure that the rules are followed and nobody tricks the rules using a PI as PA. Specially for the NCC is much simpler. > > Easy as a flat rate for every LIR. Actually this is the main problem problem for me. LIR should by the name work as local internet registry. This has been broken for IPv4 by IPv4 shortage. Not everyone should be forced to be a RIPE NCC member. I'm perfectly fine with 50 EUR fee for every /48 for those. Such organization which needs PI have no plans for assigning > > Is easier, but it is fair? This is not for the AP-WG to decide. > addresses to third parties, so why they should be LIR when they don't plan to act as one? > > The problem is that once we accepted 2016-04, that got broken. End-users being assigned a /48 are using that now to sub-assign addresses to other end-users (employees, students, users of a hot-spot, etc.). Well, most people obviously don't consider this "broken" as there has been a consensus after all. And I think we really made clear that it's not a sub-assigment, which was the whole point of the last two years. > This would make IPv6 addresses less accessible. It is like LIR saying: "Do you want to have your own addresses or more then I gave you? Go to the RIPE NCC and pay them 1400 EUR/y! No matter what you do...". Those PI users would either loose protection of their own space or they would had to pay 28x more per year plus 2000 EUR sign up fee. What would do company outside of the internet business? They would not implement IPv6, that is easy! :-) > > As said before, this is fixed in combination with the fee structure decision by the AGM. So *no*, on the contrary, will be fairer. I think probably a 50 Euros cost for a /48 is really too low, and may be a /32 will become cheaper, and of course, a /20 more expensive. There are many possible models for that, but it can be perfectly managed to avoid anyone having a requirement from a /48 to not being able to afford it. > > >> In my opinion PI should still be here, but only for a special cases, non-ISP non-LIR organizations. So if there will be any use of PI space by ISP for its clients, it should be immediately reclaimed by RIPE NCC. Also LIR should not be entitled to claim PI for itself. But this is just my point of view. > > > > So then, again, let's roll back 2016-04, because is non-sense that somebody instead of using the addressing space for their own organization as end-user, is using it for a hotspot or datacenter. > > 2016-04 is not the problem, it doesn't say that you can use PI as PA. It just allows you to use your PI range on your premise and give access to such network to the third party. It does not allow you to give whole range to CPE. > > It allows sub-assigments, which was not the intent of the original IPv6 PI, at all. This may be true but it's not relevent. The "original IPv6 PI" isn't here anymore and the community decided it should be the way it is *now*. Best Max From max at rfc2324.org Fri May 18 02:38:10 2018 From: max at rfc2324.org (Maximilian Wilhelm) Date: Fri, 18 May 2018 02:38:10 +0200 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: <12F2ECA0-5306-4ECC-848F-B2514096EB8C@consulintel.es> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> <197841dd-a3ce-80d5-ef74-58501dc7876f@uu.org> <12F2ECA0-5306-4ECC-848F-B2514096EB8C@consulintel.es> Message-ID: <20180518003810.GF8542@principal.rfc2324.org> Anno domini 2018 JORDI PALET MARTINEZ via address-policy-wg scripsit: Hi, > PI and PA are artificial names for the same thing. They are not. > There is only one type of Global Unicast Addresses in IPv6. Not true. PI and PA are sliced from different pools which may have (I didn't evaluate that by myself yet) different routing policies in the DFZ. At least I've seen filters or BCOPs for PA space differ from PI space in the means of what prefix lengths to accept. > As I already explained before, the same way the AGM created the end-user contract and the corresponding fee, they should be a new fee structure within the LIR contract, for those that have one of few /48s instead of /32 or /29, etc. And there you are mixing GM and AP-WG again. This is neither a topic for this WG, nor do I think that there would be any possible consensus about a change in charging schema. And basicly I'm with some other here: What is your real intent with all this? Simplification does not seem to be it. Best Max From jordi.palet at consulintel.es Fri May 18 09:05:58 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 18 May 2018 09:05:58 +0200 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: <20180518003810.GF8542@principal.rfc2324.org> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> <197841dd-a3ce-80d5-ef74-58501dc7876f@uu.org> <12F2ECA0-5306-4ECC-848F-B2514096EB8C@consulintel.es> <20180518003810.GF8542@principal.rfc2324.org> Message-ID: <8E6DE5CA-8768-4013-AF2B-66AC8A1B294C@consulintel.es> Hi Max, Thanks for your inputs. Responding below in-line. Regards, Jordi ?-----Mensaje original----- De: address-policy-wg en nombre de Maximilian Wilhelm Fecha: viernes, 18 de mayo de 2018, 2:38 Para: Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI Anno domini 2018 JORDI PALET MARTINEZ via address-policy-wg scripsit: Hi, > PI and PA are artificial names for the same thing. They are not. Please, enumerate what are the differences, so we can check one by one. > There is only one type of Global Unicast Addresses in IPv6. Not true. Sorry, can you point me to the RFC that points to that assertion? PI and PA are sliced from different pools which may have (I didn't evaluate that by myself yet) different routing policies in the DFZ. At least I've seen filters or BCOPs for PA space differ from PI space in the means of what prefix lengths to accept. If you look into my presentation you will see that I've already thought about that, so the NCC can continue with the same operational practices as per today: " Actual IPv6 PI assignments are made from a different block. Even if it is an operational NCC issues, I believe it still makes sense for the NCC to keep that structure (a block for ISPs with /32 and bigger allocations) and another block for /48 and bigger allocations (may be up to /33 for organizations/end-sites). Also keep using sparse allocation for both, and allow, while possible that further allocations are made from an adjacent address block." > As I already explained before, the same way the AGM created the end-user contract and the corresponding fee, they should be a new fee structure within the LIR contract, for those that have one of few /48s instead of /32 or /29, etc. And there you are mixing GM and AP-WG again. This is neither a topic for this WG, nor do I think that there would be any possible consensus about a change in charging schema. I know, but BOTH need to be worked somehow with some parallelism. I'm going to say this once more: We didn't have the end-user contract before I proposed the IPv6 PI, then the board and the AGM did the rest. So there is not any issue about repeating that. And basicly I'm with some other here: What is your real intent with all this? Simplification does not seem to be it. For full disclosure, if you still doubt about it: My intent is only doing work whenever I need it helps, for the good of the community. I'm probably the most objective guy here. I've no any LIR neither end-user (in any RIR), neither I plan. So, whatever is in the policies is not "affecting directly to me". I only had an experimental ASN and IPv6 prefix, many years ago, when I started playing with IPv6. Despite that, because you seem to think that I'm hiding something, whatever I can say will not convince you. But put yourself in this situation. When anybody submit a policy proposal, should we always think that? If we start with this kind of prejudices, will never help debating on any topic. Not really smart. So, once more, can you enumerate what are the special features from IPv6 PI, different that IPv6 PA, that I'm missing? Put aside for a moment all the issues related to fees, because even the AGM could decide to keep the exact same fees for "end-users" as per today even if we remove the IPv6 PI. So that may not change this specific aspect of the overall discussion. Best Max ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From jordi.palet at consulintel.es Fri May 18 09:21:38 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 18 May 2018 09:21:38 +0200 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: <20180517153623.GE8542@principal.rfc2324.org> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> <2116215.Frit7E0hTN@rumburak.ite.tul.cz> <147471F6-091C-4E3D-879A-8089C70DD140@consulintel.es> <2182481.LFyoZQ4taB@rumburak.ite.tul.cz> <4FF305D7-C93E-40CE-8E3B-88ABC8B60621@consulintel.es> <20180517153623.GE8542@principal.rfc2324.org> Message-ID: I will use [Jordi] to make it clear. Regards, Jordi ?-----Mensaje original----- De: address-policy-wg en nombre de Maximilian Wilhelm Fecha: jueves, 17 de mayo de 2018, 17:36 Para: Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI Anno domini 2018 JORDI PALET MARTINEZ via address-policy-wg scripsit: > Responding below, in-line. *PLEASE* use some meaningful way to quote and answer inline so a reader can distinguish between the original text and your answer. You current mode of answering is making this really hard. > > De: address-policy-wg en nombre de Martin Hun?k > > Fecha: mi?rcoles, 16 de mayo de 2018, 17:28 > > Para: , JORDI PALET MARTINEZ > > Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI > > > >> Hi Jordi, > > > >> As I understand it, the PA is only for a LIR and PI is also for sponsored organization. Also the PI is solely for the end user infrastructure and and PA can be further allocated or assigned. > > > > This is our actual definition. We can change it whenever we want. What I'm asking is what is the *real* distinction among them. Forget for a minute in contracts, fee structure and so on. There is no need to call the same with different names if we don't want. I'm calling here for simplicity. Once we remove the sub-assignment obstacle, there is not anymore a difference. > > Discussion should be about, if we want to / should remove such *obstacle*. I would personally prefer that policy about PI space would stay the same. Just RIPE NCC should be more investigative and restrictive when assigning those. > > Being Internet policy is very difficult. If we have ways to avoid that, is an easier way to achieve the same. Policies are for a fair distribution of the resources, to make that distribution simpler, not to have complex policies and then being unable to track how well anyone is behaving with them. > > > Yes, that's the idea, please see my slides. PI holders will need to become members, maybe the fee will get an increase (something on the line of a small one-time setup fee and later on a proportion of the cost of a /32 if you are getting only a /48, etc., but this is for the membership to decide). What we all win with that is a fairer cost distribution and also an easier way to make sure that the rules are followed and nobody tricks the rules using a PI as PA. Specially for the NCC is much simpler. > > Easy as a flat rate for every LIR. Actually this is the main problem problem for me. LIR should by the name work as local internet registry. This has been broken for IPv4 by IPv4 shortage. Not everyone should be forced to be a RIPE NCC member. I'm perfectly fine with 50 EUR fee for every /48 for those. Such organization which needs PI have no plans for assigning > > Is easier, but it is fair? This is not for the AP-WG to decide. [Jordi] Agree, but it was not either when we created IPv6 PI, and all the needed changes were considered in parallel. > addresses to third parties, so why they should be LIR when they don't plan to act as one? > > The problem is that once we accepted 2016-04, that got broken. End-users being assigned a /48 are using that now to sub-assign addresses to other end-users (employees, students, users of a hot-spot, etc.). Well, most people obviously don't consider this "broken" as there has been a consensus after all. And I think we really made clear that it's not a sub-assigment, which was the whole point of the last two years. [Jordi] We aren't going to discuss that over and over again. Different people who read that text has a different interpretation than the impact analysis, so objectively it is broken. > This would make IPv6 addresses less accessible. It is like LIR saying: "Do you want to have your own addresses or more then I gave you? Go to the RIPE NCC and pay them 1400 EUR/y! No matter what you do...". Those PI users would either loose protection of their own space or they would had to pay 28x more per year plus 2000 EUR sign up fee. What would do company outside of the internet business? They would not implement IPv6, that is easy! :-) > > As said before, this is fixed in combination with the fee structure decision by the AGM. So *no*, on the contrary, will be fairer. I think probably a 50 Euros cost for a /48 is really too low, and may be a /32 will become cheaper, and of course, a /20 more expensive. There are many possible models for that, but it can be perfectly managed to avoid anyone having a requirement from a /48 to not being able to afford it. > > >> In my opinion PI should still be here, but only for a special cases, non-ISP non-LIR organizations. So if there will be any use of PI space by ISP for its clients, it should be immediately reclaimed by RIPE NCC. Also LIR should not be entitled to claim PI for itself. But this is just my point of view. > > > > So then, again, let's roll back 2016-04, because is non-sense that somebody instead of using the addressing space for their own organization as end-user, is using it for a hotspot or datacenter. > > 2016-04 is not the problem, it doesn't say that you can use PI as PA. It just allows you to use your PI range on your premise and give access to such network to the third party. It does not allow you to give whole range to CPE. > > It allows sub-assigments, which was not the intent of the original IPv6 PI, at all. This may be true but it's not relevent. The "original IPv6 PI" isn't here anymore and the community decided it should be the way it is *now*. [Jordi] Right, and any community member can suggest improvements again. Best Max ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From jordi.palet at consulintel.es Fri May 18 09:40:08 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 18 May 2018 09:40:08 +0200 Subject: [address-policy-wg] 2018-02 Assignment Clarification in IPv6 Policy - comments from today meeting In-Reply-To: <7817b7d1-39ba-5067-8fc4-cadbda9ef0ac@uu.org> References: <53c22ca9-dce4-6782-61bf-9a0644a580c7@uu.org> <38E24466-EDEB-4B44-897C-FD565DCC1AC2@consulintel.es> <7817b7d1-39ba-5067-8fc4-cadbda9ef0ac@uu.org> Message-ID: <459F2760-FCE6-4C78-808A-873D2C312FFB@consulintel.es> Hi Kai, Responding below, in-line. Regards, Jordi ?-----Mensaje original----- De: address-policy-wg en nombre de Kai 'wusel' Siering Organizaci?n: Unseen University, Department of Magic Mails Fecha: mi?rcoles, 16 de mayo de 2018, 20:37 Para: Asunto: [address-policy-wg] 2018-02 Assignment Clarification in IPv6 Policy - comments from today meeting Hi there, on 16.05.2018 17:33, JORDI PALET MARTINEZ via address-policy-wg wrote: > So, to make sure I understood your point. You think that a single /128 prefix is ok to be sub-assigned (as per the current policy), but a single /64 prefix is not? > Or you will agree in a change that only fix that? I think that the current text serves it's purpose and _can_ be understood in the way it was intended to (i. e. countering the, non-standard, RIPE NCC idea that using SLAAC or DHCPv6 constitutes an act of sub-assigning addresses, forbidden as per section 2.6). [Jordi] So there is a contradiction here, because according you, only if you use manual setup, then it will not be a sub-assignment? If you read it while suffering from an overdose of technical writings, a normal reaction could be "R U kidding me? Addresses, even plural, but not prefixes ? does not compute". I do *not* agree that _that paragraph_ needs another band-aid. [Jordi] The fact that you and I are interpreting different things, shows clearly, that the text is not good. I think that rough consensus should be sought on what uses by the assignment holder of assigned IPv6 space are considered ok. Afterwards, amending the policy at least should be more easy ? if still considered necessary by then. > Regarding the specific wording, you're totally right and we should decide *if* there is a way to re-formulate it. I think we should keep it as it is, take a step back and consider what issue, if any, there is. Frankly, I do not see one ATM; policy texts should not try to micromanage the readers mind, IMO. > That's the reason I initially suggested, even when discussing 2016-04, that the text should be only in the IPv6 PI section ... the consensus was in the other direction. Well, the current policy does allow ?minor? third-party-usage for any (note the word) assigned IPv6 space. Previously, adopting RIPE NCCs view on SLAAC being an act of address assignment, no-one was allowed to run a Guest WiFi or similar with RIPE area assigned IPv6 space, PA or PI ? as sub-assignments were (and are) forbidden and providing a third party with single addresses out of an assignment holder's addresses constituted a sub-assignment according to RIPE NCC (this is now fixed per policy in ripe-699's section 2.6). So, if you agree with RIPE NCCs view, 2.6 is the correct location. If not, the policy maybe was fine and the issue lay elsewhere. [Jordi] Again, then because I'm using latest standards which allow me to use /64 per hosts, it means I can't use it. We have moved the limit to a single address while it was NONE. The community can decide then to move to a single prefix, or why not, later to several /64 prefixes ... Thinks about that please. > This is the big problem in my opinion, and I actually forgot the mention it before. I think policy must be as much as possible, a text which has only one interpretation, even if that means it is longer. Otherwise, and I explained this in emails when discussing 2016-04, people that "follows" the policy process has advantage in terms of interpretation vs a newcomer that will read only the *policy text*, but not the impact analysis, and all the discussions used to clarify the policy text. I totally disagree with you on this. The more words go into a policy, the more loopholes are opened, which then have to backfill with new wordings, leading to pages after pages of policy text. A policy text should be easy to understand (especially for non-native speakers of the english language ;)), give a guideline on what use case it expects to cover and at all costs refrain from giving examples. The thing with examples is that, from my experience, they invite people to game the rules. [Jordi] Again, newcomers have a disadvantage if the policy text is not clear enough and provides different interpretations vs the impact analysis, because the impact analysis is not *referenced* at the policy manual with every policy change (which will be way to complex). Please don't overengineer the policies. [Jordi] On the other way around, I'm trying to make sure that 1) the text is more clear or 2) we simplify all the mess by removing IPv6 PI Regards, -kai ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From he at uninett.no Fri May 18 10:53:53 2018 From: he at uninett.no (Havard Eidnes) Date: Fri, 18 May 2018 10:53:53 +0200 (CEST) Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: References: <4FF305D7-C93E-40CE-8E3B-88ABC8B60621@consulintel.es> <20180517153623.GE8542@principal.rfc2324.org> Message-ID: <20180518.105353.835813701549446414.he@uninett.no> >> > Responding below, in-line. >> >> *PLEASE* use some meaningful way to quote and answer inline so a >> reader can distinguish between the original text and your answer. You >> current mode of answering is making this really hard. > > I will use [Jordi] to make it clear. Then how far does that extend/apply? Speaking for myself, you are significantly increasing your chances of being summarily ignored if you're using difficult-to-decipher quoting conventions. Best regards, - H?vard From jprins at betterbe.com Fri May 18 12:29:22 2018 From: jprins at betterbe.com (Jan Hugo Prins | BetterBe) Date: Fri, 18 May 2018 12:29:22 +0200 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> Message-ID: I think we introduced IPv6 PI because we needed to be able to give address space to entities that only need internal address space, want to be multi-homed, but would never allocate to 3rd party networks because they would only use it internally for their own business (for example a SAAS provider hosting it's own product inhouse). When we stop allowing IPv6 PI we would force those entities to, either become a LIR and pay a lot more for the same IPv6 address space, or they will probably not start using IPv6 at all. Both would not be a good idea I think. Jan Hugo On 05/16/2018 02:52 PM, JORDI PALET MARTINEZ via address-policy-wg wrote: > Hi all, > > For those that haven't been in the meeting, the slides are available at https://ripe76.ripe.net/presentations/97-RIPE-2018-05-v1.pdf > > I believe we have several problems that my proposal is trying to fix. > > 1) See my previous email on the clarification of IPv6 PI sub-assignments. Is not just a matter of IPv6, but also IPv4. This is an alternative solution (at least of the IPv6 part - we could do the same for IPv4 of course and also remove IPv4 PI). > > 2) It was clear in the meeting, as we *all* know, that many folks in the community (and not only in this region) are abusing the policy and they actually use end-user space (PI policies) to *assign* (call it sub-assign if you prefer it), to third parties. > > 3) It may be the case that this happens because the fee structure. An LIR, currently, pays 1.400 Euros per year (plus one-time setup-fee of 2.000 Euros). And end-user just pay 50 Euros per resource assignment. So, it makes sense to just pay for 50 Euros, and then you may be providing services using NAT+CGN (in the case of IPv4) or a single /64 to each subscriber in the case of IPv6. It is broken, of course, but people do that. > > 4) The fee scheme is somehow responsible of that as well, as there is in my opinion, unfairness. A big ISP having an IPv6 /20, or /24 or /29 or /32 is paying always the same. This is the only region that have a "flat" rate. > > 5) We could fix the point above, auditing every end-user. But we could also fix it in a better way by: > a) A policy change in the line the one I've proposed (see the slides and the links for a diff) > b) Having a single LIR contract, instead of LIR and end-user > c) This may be (as an option), also become a way to make a price scheme which is proportional to the amount of resources allocated. > > Note that we don't need to change the fee scheme, but it is an opportunity for taking a look into that. It may be perfectly possible to keep the cost of end-users as 50 Euros (for a single /48, for example), but having a single contract. I know perfectly that fees are not "policy", however only if we address that we can do correctly the policy. A demonstration of that: When I proposed the IPv6 PI and it reached consensus, it was needed to create the "end-user" contract and the corresponding fee, so is something that we have done before. > > I know that the proposed text may be very imperfect, for example the usage of "ISPs", but this is not the key now, there are for sure several alternatives to that. For example, we could just differentiate both cases with "LIR that do subsequent distributions initially qualify for /32 up to /29 etc. LIRs that do not do subsequent distributions initially qualify for a /48 for each end-site". So please, don't consider specific text at this point of the discussion. > > And last, but not least, repeating myself, we could do this just for IPv6, or also work in parallel in a policy proposal for IPv4 PI removal as well. This will be probably the best choice, so we can let the NCC to have a simplified policy, a single contract and consequently less overhead: Simplification for everyone. > > Thoughts? > > > Regards, > Jordi > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > -- Kind regards Jan Hugo Prins /DevOps Engineer/ Auke Vleerstraat 140 E 7547 AN Enschede CC no. 08097527 *T* +31 (0) 53 48 00 694 *E* jprins at betterbe.com *M* +31 (0)6 263 58 951 www.betterbe.com BetterBe accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From jordi.palet at consulintel.es Sat May 19 12:07:50 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 19 May 2018 12:07:50 +0200 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> Message-ID: <36C21C5F-3FCE-4022-8FA5-93698D218137@consulintel.es> Hi Jan, We introduced IPv6 PI (I was the author of that policy proposal), because (in this order): 1) There was a claim for it considering that this will help the deployment of IPv6 (your claim for multihoming) 2) It existed in IPv4, so people wanted the same ... 3) It was a way to avoid creating an IPv6 NAT (somehow your mention about internal addresses) 4) ... there were many other minor considerations at that time However, I always stated clearly when I was presenting my own proposal that I was "not" personally in favor of that, and I was only doing that because the community considered that need. But, I think it is clear now that the main reason (1), was not really an obstacle for the IPv6 deployment, and in fact, where we are lacking "more" IPv6 deployment is in enterprises, so it didn't worked to resolve that problem. Now, in your text, you mention "but would never allocate to 3rd party networks because they would only use it internally for their own business" ... right, and we broke it with the 2016-4 ... My proposal is NOT to stop IPv6 PI, it is only to make a *single* category of LIRs for both that accommodate real IPv6 addressing size needs, because PI and PA are the same, it is just an artificial name. As I explained already, the intent is not to increase the end-user fees so they pay the same as an LIR, but to have some "proportionality" and to pay for the "real" NCC cost (which maybe still 50 euros, or maybe not, I don't know that, it is something that the NCC should calculate). So, lets thing for a moment that 50 Euros for an ASN, 50 for an IPv4 /22 and 50 for an IPv6 /48 (which in total is 150 Euros), it is really covering the yearly cost of the NCC to maintain those services. Maybe it is fair to just change that for 150 Euros (so no change) for LIRs which have a single end-site, but now they don't have restrictions and we avoid discussions related to if a sub-assignment is correct or not, if it is only a single address or several, and so on. If instead of that, the NCC tell us that the real cost for maintaining those services is 200 Euros, it will be fair that the LIRs aren't subsidizing the end-users, so there is an LIR category for "end-users" that becomes 200 Euros (instead of 150), and then of course, the LIRs cost will drop a bit from 1.400 Euros to maybe around 1.000 euros or whatever is the calculation that the NCC shows is the correct one (this will depend on how many LIRs we have today vs. end-users and how much is the expected increase in each category in the coming years, etc.). Beard in mind, that having a *single* member contract, means simplicity for both the NCC and the members, which means somehow a (marginal) administrative cost decrease, but also simplification for the policies, less interpretation errors, less people trying to bend the policies to the limit, etc., etc. It is up to the NCC to provide possible fee schemes to accommodate several possibilities, in order the ensure a long-term sustainability of the system and also a *fair* distribution of the real costs. For example, it may be interesting also to consider if the "setup" fee should be really 2.000 euros, or something different (even less than half), if we have a double number of LIRs (when putting together a single contract for all), of if this one-time setup fee must be much lower to accommodate the "real" one-time-setup cost, and then pay just 10 extra (just an example) euros per year in the yearly fee, which is probably more interesting in terms of "long-term" NCC sustainability. Last comment. I can't believe that and end-user, even a small company, is willing to pay to have a BGP router and capable staff (or external services to manage that), and has *an* issue to cover a few extra euros per year in case the (to be defined) "LIR fee for end-users" is 200 or even 500 Euros (again just examples) instead of 150 Euros. Regards, Jordi ?-----Mensaje original----- De: address-policy-wg en nombre de Jan Hugo Prins | BetterBe Fecha: viernes, 18 de mayo de 2018, 12:30 Para: Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI I think we introduced IPv6 PI because we needed to be able to give address space to entities that only need internal address space, want to be multi-homed, but would never allocate to 3rd party networks because they would only use it internally for their own business (for example a SAAS provider hosting it's own product inhouse). When we stop allowing IPv6 PI we would force those entities to, either become a LIR and pay a lot more for the same IPv6 address space, or they will probably not start using IPv6 at all. Both would not be a good idea I think. Jan Hugo On 05/16/2018 02:52 PM, JORDI PALET MARTINEZ via address-policy-wg wrote: > Hi all, > > For those that haven't been in the meeting, the slides are available at https://ripe76.ripe.net/presentations/97-RIPE-2018-05-v1.pdf > > I believe we have several problems that my proposal is trying to fix. > > 1) See my previous email on the clarification of IPv6 PI sub-assignments. Is not just a matter of IPv6, but also IPv4. This is an alternative solution (at least of the IPv6 part - we could do the same for IPv4 of course and also remove IPv4 PI). > > 2) It was clear in the meeting, as we *all* know, that many folks in the community (and not only in this region) are abusing the policy and they actually use end-user space (PI policies) to *assign* (call it sub-assign if you prefer it), to third parties. > > 3) It may be the case that this happens because the fee structure. An LIR, currently, pays 1.400 Euros per year (plus one-time setup-fee of 2.000 Euros). And end-user just pay 50 Euros per resource assignment. So, it makes sense to just pay for 50 Euros, and then you may be providing services using NAT+CGN (in the case of IPv4) or a single /64 to each subscriber in the case of IPv6. It is broken, of course, but people do that. > > 4) The fee scheme is somehow responsible of that as well, as there is in my opinion, unfairness. A big ISP having an IPv6 /20, or /24 or /29 or /32 is paying always the same. This is the only region that have a "flat" rate. > > 5) We could fix the point above, auditing every end-user. But we could also fix it in a better way by: > a) A policy change in the line the one I've proposed (see the slides and the links for a diff) > b) Having a single LIR contract, instead of LIR and end-user > c) This may be (as an option), also become a way to make a price scheme which is proportional to the amount of resources allocated. > > Note that we don't need to change the fee scheme, but it is an opportunity for taking a look into that. It may be perfectly possible to keep the cost of end-users as 50 Euros (for a single /48, for example), but having a single contract. I know perfectly that fees are not "policy", however only if we address that we can do correctly the policy. A demonstration of that: When I proposed the IPv6 PI and it reached consensus, it was needed to create the "end-user" contract and the corresponding fee, so is something that we have done before. > > I know that the proposed text may be very imperfect, for example the usage of "ISPs", but this is not the key now, there are for sure several alternatives to that. For example, we could just differentiate both cases with "LIR that do subsequent distributions initially qualify for /32 up to /29 etc. LIRs that do not do subsequent distributions initially qualify for a /48 for each end-site". So please, don't consider specific text at this point of the discussion. > > And last, but not least, repeating myself, we could do this just for IPv6, or also work in parallel in a policy proposal for IPv4 PI removal as well. This will be probably the best choice, so we can let the NCC to have a simplified policy, a single contract and consequently less overhead: Simplification for everyone. > > Thoughts? > > > Regards, > Jordi > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > -- Kind regards Jan Hugo Prins /DevOps Engineer/ Auke Vleerstraat 140 E 7547 AN Enschede CC no. 08097527 *T* +31 (0) 53 48 00 694 *E* jprins at betterbe.com *M* +31 (0)6 263 58 951 www.betterbe.com BetterBe accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From gert at space.net Sat May 19 12:17:34 2018 From: gert at space.net (Gert Doering) Date: Sat, 19 May 2018 12:17:34 +0200 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: <36C21C5F-3FCE-4022-8FA5-93698D218137@consulintel.es> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> <36C21C5F-3FCE-4022-8FA5-93698D218137@consulintel.es> Message-ID: <20180519101734.GX89741@Space.Net> Hi, On Sat, May 19, 2018 at 12:07:50PM +0200, JORDI PALET MARTINEZ via address-policy-wg wrote: > My proposal is NOT to stop IPv6 PI, it is only to make a *single* > category of LIRs for both that accommodate real IPv6 addressing > size needs, because PI and PA are the same, it is just an artificial > name. Speaking for my PI-holding (IPv4 and IPv6) customers, most of them do not *want* to be a LIR. They have a nice contract with a local company (us) that does all the paperwork for them, speaks their local language, they can visit our office if needed, we handle the international money transfer bit, etc. Some *cannot* become a LIR due to governing laws that disallow them to join any sort of association. So "doing away with end-users that have their own space and are not a RIPE member" is not going to fly. Gert Doering -- speaking as sponsoring LIR admin -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From jordi.palet at consulintel.es Sat May 19 12:34:33 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 19 May 2018 12:34:33 +0200 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: <20180519101734.GX89741@Space.Net> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> <36C21C5F-3FCE-4022-8FA5-93698D218137@consulintel.es> <20180519101734.GX89741@Space.Net> Message-ID: <8C607481-C44A-46F8-AC77-06CAB32C1E35@consulintel.es> Hi Gert, This sounds strange to me, specially the "laws" bit. Unless I'm wrong on this, the other RIRs don't have that "special end-user contract", the membership agreement is the same, and never heard about a single case which it was a trouble at all. Having somebody that do the paperwork for becoming an LIR and any associated work, is something that is being done already today for many companies, so I don't think there is no reason for that being a showstopper. In fact, this is something very common in many business activities (and just for our sector). Last, but not least, we could keep the "end-user" agreement if this is a real problem, but still unify PI and PA. Basically the policy text will say "If you have a need for end-site addressing, such as /48, you will get it *allocated* under the end-user agreement. If you have a need for /32 ... etc ... you will get it *allocated* under the LIR agreement". I think the point that need to be clear is that by removing IPv6 PI, my intent is not to create troubles to anyone, but on the other way around, to simplify and to avoid complex policy text that disallows (because it is assigment instead of allocation), things that *allocations* allows ... which create artificial barriers and bending the rules or their interpretation. Regards, Jordi ?-----Mensaje original----- De: address-policy-wg en nombre de Gert Doering Fecha: s?bado, 19 de mayo de 2018, 12:17 Para: JORDI PALET MARTINEZ CC: Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI Hi, On Sat, May 19, 2018 at 12:07:50PM +0200, JORDI PALET MARTINEZ via address-policy-wg wrote: > My proposal is NOT to stop IPv6 PI, it is only to make a *single* > category of LIRs for both that accommodate real IPv6 addressing > size needs, because PI and PA are the same, it is just an artificial > name. Speaking for my PI-holding (IPv4 and IPv6) customers, most of them do not *want* to be a LIR. They have a nice contract with a local company (us) that does all the paperwork for them, speaks their local language, they can visit our office if needed, we handle the international money transfer bit, etc. Some *cannot* become a LIR due to governing laws that disallow them to join any sort of association. So "doing away with end-users that have their own space and are not a RIPE member" is not going to fly. Gert Doering -- speaking as sponsoring LIR admin -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From nick at foobar.org Sat May 19 14:20:58 2018 From: nick at foobar.org (Nick Hilliard) Date: Sat, 19 May 2018 13:20:58 +0100 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: <36C21C5F-3FCE-4022-8FA5-93698D218137@consulintel.es> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> <36C21C5F-3FCE-4022-8FA5-93698D218137@consulintel.es> Message-ID: JORDI PALET MARTINEZ via address-policy-wg wrote: > But, I think it is clear now that the main reason (1), was not > really an obstacle for the IPv6 deployment, and in fact, where we > are lacking "more" IPv6 deployment is in enterprises, so it didn't > worked to resolve that problem. You're misremembering the problem. The reason for the IPv6 PI policy was not that it was going to help deployment of IPv6, but instead that the lack of easily available, provider-portable IPv6 address space would create unnecessary obstacles to deployment. This hasn't changed. > Beard in mind, that having a *single* member contract, means > simplicity for both the NCC and the members, which means somehow a > (marginal) administrative cost decrease, but also simplification for > the policies, less interpretation errors, less people trying to bend > the policies to the limit, etc., etc. There are ~2600 IPv6 PI assignments associated with ~2450 individual organisations. Your proposal seems to require that these end-user-to-LIR contracts are replaced with end-user-to-RIPENCC contracts. Can you elaborate on how you see this being handled? And what would the RIPE NCC do if an end-user declined to change? Nick From apwg at c4inet.net Sat May 19 15:09:03 2018 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Sat, 19 May 2018 14:09:03 +0100 Subject: [address-policy-wg] [Ext] Re: proposal to remove IPv6 PI In-Reply-To: References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> <20180516162932.GK17209@cilantro.c4inet.net> <20180516163532.GF89741@Space.Net> <20180516165522.GL17209@cilantro.c4inet.net> Message-ID: <20180519130903.GM17209@cilantro.c4inet.net> On Thu, May 17, 2018 at 12:17:43AM +0000, Leo Vegoda wrote: >> but it removes the requirement that a LIR provide >> connectivity to an End User. > >Since when has this been a requirement? > >Section 2.4 of ripe-699 defines LIRs and describes them as "primarily" >providing addresses for network services that they provide. Have I >misunderstood the policy, or is there currently a requirement that LIR >provide network connectivity to the users of the addresses they assign or >sub-allocate? It's not a formal requirement but, de-facto, if the holder of PA resources wants connectivity, they have to get it from the LIR. Otherwise, why would there be a necessity for "provider-aggregateable" resources? rgds, Sascha Luck From apwg at c4inet.net Sat May 19 15:47:35 2018 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Sat, 19 May 2018 14:47:35 +0100 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> <20180516162932.GK17209@cilantro.c4inet.net> <20180516163532.GF89741@Space.Net> <20180516165522.GL17209@cilantro.c4inet.net> Message-ID: <20180519134735.GN17209@cilantro.c4inet.net> On Wed, May 16, 2018 at 07:25:27PM +0200, JORDI PALET MARTINEZ via address-policy-wg wrote: >I don't see why this would mean "lower" number of LIRs? > >Actually, I think will be the contrary. I think most of the end-users will become LIRs, especially if the AGM makes a smart move about how to attract them (fee scheme, contract, etc.). I don't see why this would be desirable. If every end-user had to become a LIR, it would blow the NCC up into this humongous bureaucratic apparatus and, perhaps more importantly, make it a regional monopoly in the truest sense - every business and person needing internet resources would be *forced* to deal with the NCC. >I don't see also why this would create more disaggregation. >The actual end-users will become LIRs. The actual LIRs will remain as LIRs. Both of them will announce the same addressing space. >In summary: Who needs to have stable addresses and avoid renumbering if changing ISP or data center, or whatever, will be an LIRs. We are coming at this from opposite sides. What I would like to see is that businesses and people who need (portable) resources don't *have to* become LIRs. Instead they contact their friendly neighbourhood sponsoring LIR and deal through them. >What I'm missing from your rationale for having those opinions? Many of the LIRs in existence today *do not want to be LIRs*. They have become LIRs mostly because it was the only way for them to get (more) IPv4 resources or they needed portable resources. These LIRs have no interest and, often, no skills in dealing with the RIPE NCC. What I am proposing is, in essence, that LIRs become "sponsoring LIRs" for all resources. No more difference between "ASSIGNED PA" and "ALLOCATED PI", everything becomes, for practical purposes, "SUB-ALLOCATED" This enables LIRs with an interest to become resource management services for those who do *not* have this interest. End Users can choose a LIR to provide these services, if they are not happy with it, they can chose another and -that's the important difference - take their resources with them without having to renumber. Or, if they so chose, can become LIRs themselves. I've actually heard, as an argument for NAT66, that the users in question want to deploy that so they can avoid renumbering when changing connectivity providers. This could be avoided if those resources became portable. It should also have a positive effect on ripedb data quality if all resources are under the care of LIRs with the skills and an interest in their management. It reduces harm to end users' operations if a LIR is shut down for whatever reason. End users can simply switch to another sponsoring LIR. It may solve the issues that some large (governmental) orgs are having with policies and distributed resource management. There may be a de-aggregation effect, this can possibly be mitigated by minimum sub-allocation sizes though that may be wasteful. "SUB-ALLOCATED PA" already does a lot of this but a few changes are needed: - make SUB-ALLOCATED resources portable - change the subsequent allocation criteria to take account of SUB-ALLOCATED space, so it is possible for "sponsoring LIRs" to receive additional allocations even if SUB-ALLOCATED is not 90% assigned. rgds, Sascha Luck >???-----Mensaje original----- >De: address-policy-wg en nombre de "Sascha Luck [ml]" >Fecha: mi??rcoles, 16 de mayo de 2018, 18:55 >Para: Gert Doering >CC: >Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI > > Hi Gert, > > On Wed, May 16, 2018 at 06:35:32PM +0200, Gert Doering wrote: > >> In other words, decouple the "LIR" function from the "ISP" > >> function. > > > >Well, that seems to be what Jordi's idea seems to be about - but it > >is neither easy nor straightforward how to get there. We've tried > >a few years ago, and when you mix in "fees", "membership / voting rights" > >and "allocation size", things get amazingly complicated... > > I think it would actually simplify a lot of those issues. It > doesn't remove the RIR->LIR->End User hierarchy but it removes > the requirement that a LIR provide connectivity to an End User. > (Basically, every LIR becomes a "sponsoring LIR") > > This removes the need for ISPs or hosters to be LIRs where they > neither want to nor have the necessary skills or the time. > > The outcome would most likely be a lot fewer LIRs with a lot > higher fees but they can of course recoup these via fees to their > end users. > > The only negative I can see is deaggregation of IPv6 space but I > think that particular boat sailed a long time ago... > > rgds, > Sascha Luck > > > > >(And if you are *not* looking at these aspects, removing the PA/PI > >label isn't actually achieving much, except replacing it by a "block > >for member" vs. "block for non-member" label, no?) > > > >Gert Doering > > -- APWG chair > >-- > >have you enabled IPv6 on something today...? > > > >SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer > >Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > >D-80807 Muenchen HRB: 136055 (AG Muenchen) > >Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > > > > > > >********************************************** >IPv4 is over >Are you ready for the new Internet ? >http://www.consulintel.es >The IPv6 Company > >This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > From gert at space.net Sat May 19 17:12:45 2018 From: gert at space.net (Gert Doering) Date: Sat, 19 May 2018 17:12:45 +0200 Subject: [address-policy-wg] [Ext] Re: proposal to remove IPv6 PI In-Reply-To: <20180519130903.GM17209@cilantro.c4inet.net> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> <20180516162932.GK17209@cilantro.c4inet.net> <20180516163532.GF89741@Space.Net> <20180516165522.GL17209@cilantro.c4inet.net> <20180519130903.GM17209@cilantro.c4inet.net> Message-ID: <20180519151245.GZ89741@Space.Net> Hi, On Sat, May 19, 2018 at 02:09:03PM +0100, Sascha Luck [ml] wrote: > It's not a formal requirement but, de-facto, if the holder of PA > resources wants connectivity, they have to get it from the LIR. > Otherwise, why would there be a necessity for > "provider-aggregateable" resources? That is the "traditional" ISP=LIR model. Especially in the government and enterprise market, there's other models today, like "the government LIR holds a /26, each region in a country has a /32 out of that, and each region is free to pick their own ISP to have the /32 routed". (The impact to the routing table is is about the same as "each region has their own LIR", but for internal administrative reasons these setups prefer to have a common address space for all official networks...) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From wusel+ml at uu.org Sat May 19 18:11:39 2018 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Sat, 19 May 2018 18:11:39 +0200 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: <36C21C5F-3FCE-4022-8FA5-93698D218137@consulintel.es> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> <36C21C5F-3FCE-4022-8FA5-93698D218137@consulintel.es> Message-ID: <563c69b6-3dd7-ea5c-fef7-7289462f4548@uu.org> Am 19.05.2018 um 12:07 schrieb JORDI PALET MARTINEZ via address-policy-wg: > My proposal is NOT to stop IPv6 PI, Alternative facts? The title says "to remove IPv6 PI". > As I explained already, the intent is not to increase the end-user fees so they pay the same as an LIR, but to have some "proportionality" and to pay for the "real" NCC cost (which maybe still 50 euros, or maybe not, I don't know that, it is something that the NCC should calculate). I've read multiple times that costs are out of scope for the APWG. So without a change towards a per resource fee structure ? which is out of scope here ?, the proposed change forces PIv6 holders to either become a LIR at 1400,-- EUR/year or abandon their assignment. Regards, -kai From phessler at theapt.org Sat May 19 18:16:59 2018 From: phessler at theapt.org (Peter Hessler) Date: Sat, 19 May 2018 18:16:59 +0200 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: <563c69b6-3dd7-ea5c-fef7-7289462f4548@uu.org> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> <36C21C5F-3FCE-4022-8FA5-93698D218137@consulintel.es> <563c69b6-3dd7-ea5c-fef7-7289462f4548@uu.org> Message-ID: <20180519161658.GJ62396@gir.theapt.org> On 2018 May 19 (Sat) at 18:11:39 +0200 (+0200), Kai 'wusel' Siering wrote: :Am 19.05.2018 um 12:07 schrieb JORDI PALET MARTINEZ via address-policy-wg: :> My proposal is NOT to stop IPv6 PI, : :Alternative facts? The title says "to remove IPv6 PI". : :> As I explained already, the intent is not to increase the end-user fees so they pay the same as an LIR, but to have some "proportionality" and to pay for the "real" NCC cost (which maybe still 50 euros, or maybe not, I don't know that, it is something that the NCC should calculate). : :I've read multiple times that costs are out of scope for the APWG. So without a change towards a per resource fee structure ? which is out of scope here ?, the proposed change forces PIv6 holders to either become a LIR at 1400,-- EUR/year or abandon their assignment. : :Regards, :-kai : : If my choices are to pay 28x my current fee or abandon using IPv6, I will abandon using IPv6. Quite simply, I can't afford it and **it isn't worth it**. Since I would like to use IPv6, I am very strongly against this proposal. -- Law of the Perversity of Nature: You cannot successfully determine beforehand which side of the bread to butter. From jordi.palet at consulintel.es Sun May 20 11:02:45 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sun, 20 May 2018 11:02:45 +0200 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> <36C21C5F-3FCE-4022-8FA5-93698D218137@consulintel.es> Message-ID: <60657B81-8453-4C6C-98B3-107605ADCE40@consulintel.es> I think it has been proven that lack of IPv6 PI was not an obstacle, just lazy people and no "immediate" incentives, and we are still with the same situation. Regarding the "conversion" of the end-user contracts into LIR contracts, there are two choices: 1) The same way as NCC did to convert the "previous" non-contractual IPv4 PI holders to the end-user contract 2) We could decide to keep the end-user contract, but still "merge" the PI and PA policies (end-users get *allocated* one /48 for each end-site and sign end user, LIRs get allocated from /32 and sign LIR contract). Regards, Jordi ?-----Mensaje original----- De: Nick Hilliard Fecha: s?bado, 19 de mayo de 2018, 14:21 Para: JORDI PALET MARTINEZ CC: Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI JORDI PALET MARTINEZ via address-policy-wg wrote: > But, I think it is clear now that the main reason (1), was not > really an obstacle for the IPv6 deployment, and in fact, where we > are lacking "more" IPv6 deployment is in enterprises, so it didn't > worked to resolve that problem. You're misremembering the problem. The reason for the IPv6 PI policy was not that it was going to help deployment of IPv6, but instead that the lack of easily available, provider-portable IPv6 address space would create unnecessary obstacles to deployment. This hasn't changed. > Beard in mind, that having a *single* member contract, means > simplicity for both the NCC and the members, which means somehow a > (marginal) administrative cost decrease, but also simplification for > the policies, less interpretation errors, less people trying to bend > the policies to the limit, etc., etc. There are ~2600 IPv6 PI assignments associated with ~2450 individual organisations. Your proposal seems to require that these end-user-to-LIR contracts are replaced with end-user-to-RIPENCC contracts. Can you elaborate on how you see this being handled? And what would the RIPE NCC do if an end-user declined to change? Nick ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From jordi.palet at consulintel.es Sun May 20 11:48:32 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sun, 20 May 2018 11:48:32 +0200 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: <20180519134735.GN17209@cilantro.c4inet.net> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> <20180516162932.GK17209@cilantro.c4inet.net> <20180516163532.GF89741@Space.Net> <20180516165522.GL17209@cilantro.c4inet.net> <20180519134735.GN17209@cilantro.c4inet.net> Message-ID: <1CC9C2BE-901E-440D-9861-1DCC852B23D2@consulintel.es> Hi Sascha, Below in-line. Regards, Jordi ?-----Mensaje original----- De: address-policy-wg en nombre de "Sascha Luck [ml]" Fecha: s?bado, 19 de mayo de 2018, 15:47 Para: Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI On Wed, May 16, 2018 at 07:25:27PM +0200, JORDI PALET MARTINEZ via address-policy-wg wrote: >I don't see why this would mean "lower" number of LIRs? > >Actually, I think will be the contrary. I think most of the end-users will become LIRs, especially if the AGM makes a smart move about how to attract them (fee scheme, contract, etc.). I don't see why this would be desirable. If every end-user had to become a LIR, it would blow the NCC up into this humongous bureaucratic apparatus and, perhaps more importantly, make it a regional monopoly in the truest sense - every business and person needing internet resources would be *forced* to deal with the NCC. [Jordi] I'm not sure there is any monopoly issue, but this is up to the NCC to evaluate. As explained in previous emails, this is just one choice, but we have the choice to unify the policy so everything is "allocation", but still have two contracts. >I don't see also why this would create more disaggregation. >The actual end-users will become LIRs. The actual LIRs will remain as LIRs. Both of them will announce the same addressing space. >In summary: Who needs to have stable addresses and avoid renumbering if changing ISP or data center, or whatever, will be an LIRs. We are coming at this from opposite sides. What I would like to see is that businesses and people who need (portable) resources don't *have to* become LIRs. Instead they contact their friendly neighbourhood sponsoring LIR and deal through them. [Jordi] I understand your point, which has been made by several folks already. What I feel strange is that this is the only region out of 5 RIRs, having this issue. Sometime we "get accommodated" to something and even if is not the best option, we don't like to change ... However, as said, having only "allocations" doesn't force us to have a single contract. It may be end-user contract for allocations of /48 per end-site and LIR contract for /32 and up. Remember also that many (small) LIRs are *today* done by other LIRs who manage the thing for them, so again no issue from my perspective. >What I'm missing from your rationale for having those opinions? Many of the LIRs in existence today *do not want to be LIRs*. They have become LIRs mostly because it was the only way for them to get (more) IPv4 resources or they needed portable resources. These LIRs have no interest and, often, no skills in dealing with the RIPE NCC. What I am proposing is, in essence, that LIRs become "sponsoring LIRs" for all resources. No more difference between "ASSIGNED PA" and "ALLOCATED PI", everything becomes, for practical purposes, "SUB-ALLOCATED" [Jordi] That's my main point. Everything becomes "allocated", so we end the endless discussion about if sub-assigment for this or that is correct or not. This enables LIRs with an interest to become resource management services for those who do *not* have this interest. End Users can choose a LIR to provide these services, if they are not happy with it, they can chose another and -that's the important difference - take their resources with them without having to renumber. Or, if they so chose, can become LIRs themselves. I've actually heard, as an argument for NAT66, that the users in question want to deploy that so they can avoid renumbering when changing connectivity providers. This could be avoided if those resources became portable. It should also have a positive effect on ripedb data quality if all resources are under the care of LIRs with the skills and an interest in their management. It reduces harm to end users' operations if a LIR is shut down for whatever reason. End users can simply switch to another sponsoring LIR. It may solve the issues that some large (governmental) orgs are having with policies and distributed resource management. There may be a de-aggregation effect, this can possibly be mitigated by minimum sub-allocation sizes though that may be wasteful. "SUB-ALLOCATED PA" already does a lot of this but a few changes are needed: - make SUB-ALLOCATED resources portable - change the subsequent allocation criteria to take account of SUB-ALLOCATED space, so it is possible for "sponsoring LIRs" to receive additional allocations even if SUB-ALLOCATED is not 90% assigned. rgds, Sascha Luck >???-----Mensaje original----- >De: address-policy-wg en nombre de "Sascha Luck [ml]" >Fecha: mi??rcoles, 16 de mayo de 2018, 18:55 >Para: Gert Doering >CC: >Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI > > Hi Gert, > > On Wed, May 16, 2018 at 06:35:32PM +0200, Gert Doering wrote: > >> In other words, decouple the "LIR" function from the "ISP" > >> function. > > > >Well, that seems to be what Jordi's idea seems to be about - but it > >is neither easy nor straightforward how to get there. We've tried > >a few years ago, and when you mix in "fees", "membership / voting rights" > >and "allocation size", things get amazingly complicated... > > I think it would actually simplify a lot of those issues. It > doesn't remove the RIR->LIR->End User hierarchy but it removes > the requirement that a LIR provide connectivity to an End User. > (Basically, every LIR becomes a "sponsoring LIR") > > This removes the need for ISPs or hosters to be LIRs where they > neither want to nor have the necessary skills or the time. > > The outcome would most likely be a lot fewer LIRs with a lot > higher fees but they can of course recoup these via fees to their > end users. > > The only negative I can see is deaggregation of IPv6 space but I > think that particular boat sailed a long time ago... > > rgds, > Sascha Luck > > > > >(And if you are *not* looking at these aspects, removing the PA/PI > >label isn't actually achieving much, except replacing it by a "block > >for member" vs. "block for non-member" label, no?) > > > >Gert Doering > > -- APWG chair > >-- > >have you enabled IPv6 on something today...? > > > >SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer > >Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > >D-80807 Muenchen HRB: 136055 (AG Muenchen) > >Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > > > > > > >********************************************** >IPv4 is over >Are you ready for the new Internet ? >http://www.consulintel.es >The IPv6 Company > >This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From jordi.palet at consulintel.es Sun May 20 11:52:39 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sun, 20 May 2018 11:52:39 +0200 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: <563c69b6-3dd7-ea5c-fef7-7289462f4548@uu.org> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> <36C21C5F-3FCE-4022-8FA5-93698D218137@consulintel.es> <563c69b6-3dd7-ea5c-fef7-7289462f4548@uu.org> Message-ID: <719B1036-202E-475C-A745-B3C455832AF3@consulintel.es> Hi Kai, below. Regards, Jordi ?-----Mensaje original----- De: address-policy-wg en nombre de Kai 'wusel' Siering Organizaci?n: Unseen University, Department of Magic Mails Fecha: s?bado, 19 de mayo de 2018, 18:11 Para: Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI Am 19.05.2018 um 12:07 schrieb JORDI PALET MARTINEZ via address-policy-wg: > My proposal is NOT to stop IPv6 PI, Alternative facts? The title says "to remove IPv6 PI". [Jordi] You're taking the tittle literally. If this is a problem I will find a better one "remove differentiation between PI and PA" or whatever. I think across the emails it has been clear. What I think is needed is to remove the fact that PI is assignment and PA is allocation and the "consequences of that". Both should be the same, regardless of fees, contract type, etc. > As I explained already, the intent is not to increase the end-user fees so they pay the same as an LIR, but to have some "proportionality" and to pay for the "real" NCC cost (which maybe still 50 euros, or maybe not, I don't know that, it is something that the NCC should calculate). I've read multiple times that costs are out of scope for the APWG. So without a change towards a per resource fee structure ? which is out of scope here ?, the proposed change forces PIv6 holders to either become a LIR at 1400,-- EUR/year or abandon their assignment. [Jordi] Please read the other emails. Not an issue if that's the difficulty. The goal is that everything is "allocation". There are many possible ways to do that from the AGM perspective, and even if we don't decide that here, we must discuss it here because it provide "light" on the possible avenues. Regards, -kai ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From jordi.palet at consulintel.es Sun May 20 11:57:38 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sun, 20 May 2018 11:57:38 +0200 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: <20180519161658.GJ62396@gir.theapt.org> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> <36C21C5F-3FCE-4022-8FA5-93698D218137@consulintel.es> <563c69b6-3dd7-ea5c-fef7-7289462f4548@uu.org> <20180519161658.GJ62396@gir.theapt.org> Message-ID: Once more ... this is not the point. I mention it as one possible choice (change fees or not, change contract or not). Even if this is not up to the WG, is something that we need to explore as well. However, we can change the policy so that both PA and PI are "allocations" and there is no artificial differences in between and consequently, restrictions which are difficult to define "border lines". Regards, Jordi ?-----Mensaje original----- De: address-policy-wg en nombre de Peter Hessler Fecha: s?bado, 19 de mayo de 2018, 18:17 Para: Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI On 2018 May 19 (Sat) at 18:11:39 +0200 (+0200), Kai 'wusel' Siering wrote: :Am 19.05.2018 um 12:07 schrieb JORDI PALET MARTINEZ via address-policy-wg: :> My proposal is NOT to stop IPv6 PI, : :Alternative facts? The title says "to remove IPv6 PI". : :> As I explained already, the intent is not to increase the end-user fees so they pay the same as an LIR, but to have some "proportionality" and to pay for the "real" NCC cost (which maybe still 50 euros, or maybe not, I don't know that, it is something that the NCC should calculate). : :I've read multiple times that costs are out of scope for the APWG. So without a change towards a per resource fee structure ? which is out of scope here ?, the proposed change forces PIv6 holders to either become a LIR at 1400,-- EUR/year or abandon their assignment. : :Regards, :-kai : : If my choices are to pay 28x my current fee or abandon using IPv6, I will abandon using IPv6. Quite simply, I can't afford it and **it isn't worth it**. Since I would like to use IPv6, I am very strongly against this proposal. -- Law of the Perversity of Nature: You cannot successfully determine beforehand which side of the bread to butter. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From nick at foobar.org Sun May 20 13:17:46 2018 From: nick at foobar.org (Nick Hilliard) Date: Sun, 20 May 2018 12:17:46 +0100 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: <60657B81-8453-4C6C-98B3-107605ADCE40@consulintel.es> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> <36C21C5F-3FCE-4022-8FA5-93698D218137@consulintel.es> <60657B81-8453-4C6C-98B3-107605ADCE40@consulintel.es> Message-ID: <5d1a28fd-9193-c313-44af-187defc4892c@foobar.org> JORDI PALET MARTINEZ via address-policy-wg wrote: > I think it has been proven that lack of IPv6 PI was not an obstacle, > just lazy people and no "immediate" incentives, and we are still with > the same situation. 2400 IPv6 PI holders seem to disagree with you. > Regarding the "conversion" of the end-user contracts into LIR > contracts, there are two choices: 1) The same way as NCC did to > convert the "previous" non-contractual IPv4 PI holders to the > end-user contract The RIPE NCC argued that 2007-01 authorised them to convert an implicit end-user contract for PI holders to an explicit contract. I.e. this was an update to the terms and conditions between a contract which already existed. It looks like you're suggesting that the RIPE NCC take the sponsoring LIR business by force. This is unlikely to be legal in most of the jurisdictions that the RIPE NCC deals with. What happens if either the end user or the LIR refuse to "convert" the end-user-to-LIR contract to an end-user-to-RIPE-NCC contract? > 2) We could decide to keep the end-user contract, > but still "merge" the PI and PA policies (end-users get *allocated* > one /48 for each end-site and sign end user, LIRs get allocated from > /32 and sign LIR contract). I still don't understand what problem you're trying to solve here, or why you suggest that eliminating PI assignments is better than keeping them. The rationale that you presented in your talk at APWG was: > - Simplification of the policy and avoid discussions/inconsistencies related to sub-assignments. > > ? Contractual fairness among different type of IPv6 resource holders. There are minor issues relating to policy inconsistencies. Arguably, the most serious of those has been fixed already. I disagree that there is contractual unfairness. PI holders don't get the right to sub-assign and they don't get benefits of membership of the RIPE NCC association. Also, what happens with ASNs? All ASNs are direct assignments from the RIPE NCC, which means that unless you're also talking about getting rid of ASN assignments and LIR sponsorship, all of the legal baggage associated with that needs to stay in place. Nick From nick at foobar.org Sun May 20 13:25:44 2018 From: nick at foobar.org (Nick Hilliard) Date: Sun, 20 May 2018 12:25:44 +0100 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> Message-ID: <64019f68-1cab-05dc-4748-7e3cf02322e6@foobar.org> JORDI PALET MARTINEZ via address-policy-wg wrote: > 3) It may be the case that this happens because the fee structure. An > LIR, currently, pays 1.400 Euros per year (plus one-time setup-fee of > 2.000 Euros). And end-user just pay 50 Euros per resource assignment. So what? The people who make the decision about the ?50 per annum charge for IPv6 PI holders are the RIPE NCC members who pay ?1400 per annum. If they wanted, the price could increase, but they don't want to do this. The current ?50 fee exists because that is the membership's informed, explicit choice. Nick From wusel+ml at uu.org Sun May 20 18:53:50 2018 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Sun, 20 May 2018 18:53:50 +0200 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: <60657B81-8453-4C6C-98B3-107605ADCE40@consulintel.es> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> <36C21C5F-3FCE-4022-8FA5-93698D218137@consulintel.es> <60657B81-8453-4C6C-98B3-107605ADCE40@consulintel.es> Message-ID: Am 20.05.2018 um 11:02 schrieb JORDI PALET MARTINEZ via address-policy-wg: > I think it has been proven that lack of IPv6 PI was not an obstacle, just lazy people and no "immediate" incentives, and we are still with the same situation. > > Regarding the "conversion" of the end-user contracts into LIR contracts, there are two choices: > 1) The same way as NCC did to convert the "previous" non-contractual IPv4 PI holders to the end-user contract Luckily, it wouldn't be the "same way"; this time, PIv6 address holders are already bound by the ?RIPE policies as published on the RIPE web site and which may be amended from time to time?. For IPv4 assignments that predated the PI/PA distinction, e. g. from the early years like 1992/1993, nothing like that was agreed on (check ripe-072, ripe-104), so NCC's blackmailing ("sign this contract or we'll redistribute your used v4 space") was, trying to be polite here, a bit on the weird side. > 2) We could decide to keep the end-user contract, but still "merge" the PI and PA policies (end-users get *allocated* one /48 for each end-site and sign end user, LIRs get allocated from /32 and sign LIR contract). So, what would be the advantage? Wouldn't this simply create the incentive to have dirt-cheap ISPs running on End User address, which to prevent seems to be the motivation to start this discussion initially? Regards, -kai From dominik at clouvider.co.uk Sun May 20 20:10:13 2018 From: dominik at clouvider.co.uk (Dominik Nowacki) Date: Sun, 20 May 2018 18:10:13 +0000 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> <36C21C5F-3FCE-4022-8FA5-93698D218137@consulintel.es> <60657B81-8453-4C6C-98B3-107605ADCE40@consulintel.es>, Message-ID: <7EED1D82-E130-4764-B5D0-0D7215851D65@clouvider.co.uk> Dear Peers, I think it?s clear this will never reach a consensus. What are we still discussing here ? There?s nothing left to discuss any more. It?s a waste of valuable time. And for the record, I?m strongly against the proposal, the current system works. Had a lovely Sunday evening everyone ! With Kind Regards, Dominik Nowacki Clouvider Limited is a limited company registered in England and Wales. Registered number: 08750969. Registered office: 88 Wood Street, London, United Kingdom, EC2V 7RS. Please note that Clouvider Limited may monitor email traffic data and also the content of email for the purposes of security and staff training. This message contains confidential information and is intended only for the intended recipient. If you do not believe you are the intended recipient you should not disseminate, distribute or copy this e-mail. Please notify abuse at clouvider.net of this e-mail immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Clouvider Limited nor any of its employees therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. On 20 May 2018, at 17:54, Kai 'wusel' Siering > wrote: Am 20.05.2018 um 11:02 schrieb JORDI PALET MARTINEZ via address-policy-wg: I think it has been proven that lack of IPv6 PI was not an obstacle, just lazy people and no "immediate" incentives, and we are still with the same situation. Regarding the "conversion" of the end-user contracts into LIR contracts, there are two choices: 1) The same way as NCC did to convert the "previous" non-contractual IPv4 PI holders to the end-user contract Luckily, it wouldn't be the "same way"; this time, PIv6 address holders are already bound by the ?RIPE policies as published on the RIPE web site and which may be amended from time to time?. For IPv4 assignments that predated the PI/PA distinction, e. g. from the early years like 1992/1993, nothing like that was agreed on (check ripe-072, ripe-104), so NCC's blackmailing ("sign this contract or we'll redistribute your used v4 space") was, trying to be polite here, a bit on the weird side. 2) We could decide to keep the end-user contract, but still "merge" the PI and PA policies (end-users get *allocated* one /48 for each end-site and sign end user, LIRs get allocated from /32 and sign LIR contract). So, what would be the advantage? Wouldn't this simply create the incentive to have dirt-cheap ISPs running on End User address, which to prevent seems to be the motivation to start this discussion initially? Regards, -kai -------------- next part -------------- An HTML attachment was scrubbed... URL: From wusel+ml at uu.org Sun May 20 23:22:43 2018 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Sun, 20 May 2018 23:22:43 +0200 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> <36C21C5F-3FCE-4022-8FA5-93698D218137@consulintel.es> <563c69b6-3dd7-ea5c-fef7-7289462f4548@uu.org> <20180519161658.GJ62396@gir.theapt.org> Message-ID: <6f839ea8-dd35-e431-bf9f-e29b40ec0fd3@uu.org> Am 20.05.2018 um 11:57 schrieb JORDI PALET MARTINEZ via address-policy-wg: > Once more ... this is not the point. I mention it as one possible choice (change fees or not, change contract or not). I looks like there's not much positive feedback to your ?proposal?: I suggest to bury it ... > However, we can change the policy so that both PA and PI are "allocations" and there is no artificial differences in between and consequently, restrictions which are difficult to define "border lines". To me it seems there's not much interesst in changing this, especially as that would pave the way to a usage pattern that seems to be rather unwanted in the community (ISPing off End User address space). Regards, -kai From wusel+ml at uu.org Sun May 20 23:38:03 2018 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Sun, 20 May 2018 23:38:03 +0200 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: <1CC9C2BE-901E-440D-9861-1DCC852B23D2@consulintel.es> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> <20180516162932.GK17209@cilantro.c4inet.net> <20180516163532.GF89741@Space.Net> <20180516165522.GL17209@cilantro.c4inet.net> <20180519134735.GN17209@cilantro.c4inet.net> <1CC9C2BE-901E-440D-9861-1DCC852B23D2@consulintel.es> Message-ID: <535ed4a5-a219-6848-4b71-34e4c1b96f6e@uu.org> Am 20.05.2018 um 11:48 schrieb JORDI PALET MARTINEZ via address-policy-wg: > [Jordi] I understand your point, which has been made by several folks already. What I feel strange is that this is the only region out of 5 RIRs, having this issue. Sometime we "get accommodated" to something and even if is not the best option, we don't like to change ... I tend to think that the RIPE community comes from a different background than maybe other RIR communities, and I don't think doing things a bit differently means necessarily it's bad or not as good as it could be. On the contrary, personally I'd prefer much more openness with ARIN and APNIC, but then, that's not my turf anyway. Regards, -kai From wusel+ml at uu.org Sun May 20 23:59:44 2018 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Sun, 20 May 2018 23:59:44 +0200 Subject: [address-policy-wg] [Ext] Re: proposal to remove IPv6 PI In-Reply-To: <20180519130903.GM17209@cilantro.c4inet.net> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> <20180516162932.GK17209@cilantro.c4inet.net> <20180516163532.GF89741@Space.Net> <20180516165522.GL17209@cilantro.c4inet.net> <20180519130903.GM17209@cilantro.c4inet.net> Message-ID: <841f59b6-62bc-fe77-680b-521b533b1c8a@uu.org> Am 19.05.2018 um 15:09 schrieb Sascha Luck [ml]: > On Thu, May 17, 2018 at 12:17:43AM +0000, Leo Vegoda wrote: >>> but it removes the requirement that a LIR provide >>> connectivity to an End User. >> >> Since when has this been a requirement? >> >> Section 2.4 of ripe-699 defines LIRs and describes them as "primarily" >> providing addresses for network services that they provide. Have I >> misunderstood the policy, or is there currently a requirement that LIR >> provide network connectivity to the users of the addresses they assign or >> sub-allocate? > > It's not a formal requirement but, de-facto, if the holder of PA > resources wants connectivity, they have to get it from the LIR. > Otherwise, why would there be a necessity for > "provider-aggregateable" resources? I don't see this true anymore. Just request e. g. a /47 APNIC ALLOCATED NON-PORTABLE space, announce it under your (APNIC) ASN, works. Same works in the RIPE region, and from my perspective that's how it needs to work. As an LIR you receive a big chunk of address space, you distribute it to your sub-organisations, ISPs, End Users ? which not necessarily receive IP connectivity from you. Regards, -kai From max at rfc2324.org Mon May 21 21:32:37 2018 From: max at rfc2324.org (Maximilian Wilhelm) Date: Mon, 21 May 2018 21:32:37 +0200 Subject: [address-policy-wg] proposal to remove IPv6 PI In-Reply-To: <8E6DE5CA-8768-4013-AF2B-66AC8A1B294C@consulintel.es> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> <197841dd-a3ce-80d5-ef74-58501dc7876f@uu.org> <12F2ECA0-5306-4ECC-848F-B2514096EB8C@consulintel.es> <20180518003810.GF8542@principal.rfc2324.org> <8E6DE5CA-8768-4013-AF2B-66AC8A1B294C@consulintel.es> Message-ID: <20180521193237.GG8542@principal.rfc2324.org> Anno domini 2018 JORDI PALET MARTINEZ via address-policy-wg scripsit: Hi, [...] >> What is your real intent with all this? Simplification does not seem >> to be it. > For full disclosure, if you still doubt about it: My intent is only doing work whenever I need it helps, for the good of the community. I'm probably the most objective guy here. I've no any LIR neither end-user (in any RIR), neither I plan. So, whatever is in the policies is not "affecting directly to me". I only had an experimental ASN and IPv6 prefix, many years ago, when I started playing with IPv6. > Despite that, because you seem to think that I'm hiding something, whatever I can say will not convince you. But put yourself in this situation. When anybody submit a policy proposal, should we always think that? If we start with this kind of prejudices, will never help debating on any topic. Not really smart. Now it's getting personal, which I really don't approve. After read throught the whole thread it seems that no one else asking the same or similar questions is getting the same treatment, so I have to ask myself why I do. > So, once more, can you enumerate what are the special features from IPv6 PI, different that IPv6 PA, that I'm missing? I don't want to repeat myself or others. > Put aside for a moment all the issues related to fees, because even the AGM could decide to keep the exact same fees for "end-users" as per today even if we remove the IPv6 PI. So that may not change this specific aspect of the overall discussion. Even *IF* the fee issue wouldn't be touched we would have the issue that some entities - like the RIPE NCC - cannot ever be a RIPE member, hence the use of PI space at the meetings. This will apply to others. To sum this up: I'm totally against this change as it *will* create a whole bunch of new problems, obviously isn't anywhere near a possible (even rought) consensus and I don't see a positive cost / gain ratio. Best Max From apwg at c4inet.net Mon May 21 21:54:40 2018 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Mon, 21 May 2018 20:54:40 +0100 Subject: [address-policy-wg] [Ext] Re: proposal to remove IPv6 PI In-Reply-To: <20180519151245.GZ89741@Space.Net> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> <20180516162932.GK17209@cilantro.c4inet.net> <20180516163532.GF89741@Space.Net> <20180516165522.GL17209@cilantro.c4inet.net> <20180519130903.GM17209@cilantro.c4inet.net> <20180519151245.GZ89741@Space.Net> Message-ID: <20180521195440.GA99066@cilantro.c4inet.net> Hi Gert, On Sat, May 19, 2018 at 05:12:45PM +0200, Gert Doering wrote: >Especially in the government and enterprise market, there's other models >today, like "the government LIR holds a /26, each region in a country >has a /32 out of that, and each region is free to pick their own ISP >to have the /32 routed". Right. So all that is needed to dispose of PIv6 is to make these /32s portable and perhaps a change in additional allocation calculations in order to let the LIR get more resources if the existing (sub-allocated) resources are not sufficiently utilized. rgds, Sascha Luck > >(The impact to the routing table is is about the same as "each region >has their own LIR", but for internal administrative reasons these setups >prefer to have a common address space for all official networks...) > >Gert Doering > -- APWG chair >-- >have you enabled IPv6 on something today...? > >SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer >Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann >D-80807 Muenchen HRB: 136055 (AG Muenchen) >Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From gert at space.net Mon May 21 22:18:19 2018 From: gert at space.net (Gert Doering) Date: Mon, 21 May 2018 22:18:19 +0200 Subject: [address-policy-wg] [Ext] Re: proposal to remove IPv6 PI In-Reply-To: <20180521195440.GA99066@cilantro.c4inet.net> References: <00813B1D-6D4B-49ED-B46F-1D69D52F2ADD@consulintel.es> <20180516162932.GK17209@cilantro.c4inet.net> <20180516163532.GF89741@Space.Net> <20180516165522.GL17209@cilantro.c4inet.net> <20180519130903.GM17209@cilantro.c4inet.net> <20180519151245.GZ89741@Space.Net> <20180521195440.GA99066@cilantro.c4inet.net> Message-ID: <20180521201819.GI1546@Space.Net> Hi, On Mon, May 21, 2018 at 08:54:40PM +0100, Sascha Luck [ml] wrote: > On Sat, May 19, 2018 at 05:12:45PM +0200, Gert Doering wrote: > >Especially in the government and enterprise market, there's other models > >today, like "the government LIR holds a /26, each region in a country > >has a /32 out of that, and each region is free to pick their own ISP > >to have the /32 routed". > > Right. So all that is needed to dispose of PIv6 is to make these > /32s portable and perhaps a change in additional allocation > calculations in order to let the LIR get more resources if the > existing (sub-allocated) resources are not sufficiently utilized. This is not *exactly* the same as a "/48". Just sayin' Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From gert at space.net Tue May 22 12:47:25 2018 From: gert at space.net (Gert Doering) Date: Tue, 22 May 2018 12:47:25 +0200 Subject: [address-policy-wg] 2018-01 Review Phase (Organisation-LIR Clarification in IPv6 Policy) In-Reply-To: References: Message-ID: <20180522104725.GA1848@Space.Net> Dear AP WG, On Thu, May 03, 2018 at 05:08:25PM +0200, Marco Schmidt wrote: > Policy proposal 2018-01, "Organisation-LIR Clarification in IPv6 Policy" is now in the Review Phase. [..] > We encourage you to read the proposal, impact analysis and draft document and send any comments to before 1 June 2018. We could use a few more comments on this proposal. It is in review phase, so there was quite a bit of support in discussion phase, but what we've seen so far was mostly a discussion about "a LIR" or "an LIR" and not so much on the merits of the proposed change... Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From alex at vpsville.ru Fri May 25 15:00:42 2018 From: alex at vpsville.ru (Alexey Galaev) Date: Fri, 25 May 2018 16:00:42 +0300 (MSK) Subject: [address-policy-wg] 2018-01 Review Phase (Organisation-LIR Clarification in IPv6 Policy) In-Reply-To: References: Message-ID: <1528611060.115262.1527253242716.JavaMail.zimbra@vpsville.ru> Dear colleges. I fully support the proposal because it has no negative consequences. It is very small and puts the current policy in the right order. If the new LIR can get the IPv4 network I don't see any reasons why new LIR can't get the IPv6 network. We must support the development of IPv6 but not create problems with IPv6. This proposal is like small fix on github. I don't see any reasons to not approve it. I think that "a LIR" or "an LIR" doesn't matter. BR, Alexey Galaev +7 985 3608004, http://vpsville.ru http://cloudville.ru ----- Original Message ----- From: "Marco Schmidt" To: "address-policy-wg" Sent: Thursday, May 3, 2018 6:08:25 PM Subject: [address-policy-wg] 2018-01 Review Phase (Organisation-LIR Clarification in IPv6 Policy) Dear colleagues, Policy proposal 2018-01, "Organisation-LIR Clarification in IPv6 Policy" is now in the Review Phase. This proposal aims to clarify the wording used in ripe-699 regarding terms such as "organisation" and "LIR". The proposal has been updated following the last round of discussion and is now at version v2.0. Some of the differences from version v1.0 include: - Clarifies when the subsequent allocation policy applies - Fixing some typos The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community?s discussion. You can find the full proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2018-01 And the draft documents at: https://www.ripe.net/participate/policies/proposals/2018-01/draft As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussing the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. At the end of the Review Phase, the WG Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. We encourage you to read the proposal, impact analysis and draft document and send any comments to before 1 June 2018. Kind regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From ripe-wgs at radu-adrian.feurdean.net Sun May 27 23:38:48 2018 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Sun, 27 May 2018 23:38:48 +0200 Subject: [address-policy-wg] 2018-01 Review Phase (Organisation-LIR Clarification in IPv6 Policy) In-Reply-To: References: Message-ID: <1527457128.1046605.1387389488.2F8355FA@webmail.messagingengine.com> I strongly support this policy. Makes things clear and outcomes predictable (I even suspect implementation of the current policy to be occasionally/randomly "bent" towards something more in line with what this proposal aims) -- Radu-Adrian FEURDEAN