From ripedenis at yahoo.co.uk Mon Mar 4 12:30:16 2019 From: ripedenis at yahoo.co.uk (ripedenis at yahoo.co.uk) Date: Mon, 4 Mar 2019 11:30:16 +0000 (UTC) Subject: [address-policy-wg] Personal data in the RIPE Database References: <245128224.13862384.1551699016844.ref@mail.yahoo.com> Message-ID: <245128224.13862384.1551699016844@mail.yahoo.com> Colleagues I have just sent a message to the Database Working Group about personal data in the RIPE Database and the next step. As this impacts slightly on address policy, which explicitly refers to contact data, and it may involve member services to manage any cleanup of data, I would appreciate input from the members of these two working groups. Perhaps you can check the message on the DB-WG list and respond with your thoughts on that list. cheersdenisco-chair DB-WG -------------- next part -------------- An HTML attachment was scrubbed... URL: From ffamax at gmail.com Wed Mar 6 08:42:17 2019 From: ffamax at gmail.com (Maxim A Piskunov) Date: Wed, 6 Mar 2019 10:42:17 +0300 Subject: [address-policy-wg] =?utf-8?q?PA_=E2=80=93_life_after_death?= Message-ID: Hi Guys! As I understand "NetUP Ltd." will loose their PA-addresses if LIR status will not recovered and customers will should renumbering their networks. I have one simple question: why not specified procedure of keeping originally allocated addresses for case when LIR-status under cancellation and LIR can't transfer PA to another LIR. Or I miss something and chance to keep addresses is exists? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey at devnull.ru Wed Mar 6 16:07:57 2019 From: sergey at devnull.ru (Sergey Myasoedov) Date: Wed, 6 Mar 2019 16:07:57 +0100 Subject: [address-policy-wg] =?utf-8?q?PA_=E2=80=93_life_after_death?= In-Reply-To: References: Message-ID: <467546175.20190306160757@devnull.ru> Hi Maxim, I believe you need to give more details about NetUp case. -- Sergey Wednesday, March 6, 2019, 8:42:17 AM, you wrote: MAP> Hi Guys! MAP> As I understand "NetUP Ltd." will loose their PA-addresses if MAP> LIR status will not recovered and customers will should renumbering their networks. MAP> I have one simple question: why not specified procedure of MAP> keeping originally allocated addresses for case when LIR-status MAP> under cancellation and LIR can't transfer PA to another LIR. MAP> Or I miss something and chance to keep addresses is exists? From president at ukraine.su Wed Mar 6 18:24:00 2019 From: president at ukraine.su (Max Tulyev) Date: Wed, 6 Mar 2019 19:24:00 +0200 Subject: [address-policy-wg] =?utf-8?q?PA_=E2=80=93_life_after_death?= In-Reply-To: References: Message-ID: <69b2647c-a6a5-4985-857b-85d32afcf8e6@ukraine.su> Hi Maxim, I remember that old good times when RIPE NCC was turned face to the community. That times in case of LIR closure assignments was converted to PI blocks and given directly to it's holders to avoid renumbering... 06.03.19 09:42, Maxim A Piskunov ????: > Hi Guys! > > As I understand "NetUP Ltd." will loose their PA-addresses if LIR status > will not recovered and customers will should renumbering their networks. > I have one simple question: why not specified procedure of keeping > originally allocated addresses for case when LIR-status under > cancellation and LIR can't transfer PA to another LIR. > Or I miss something and chance to keep addresses is exists? From it at gcxc.net Wed Mar 6 18:43:29 2019 From: it at gcxc.net (Nikolay Gorstkin) Date: Wed, 6 Mar 2019 20:43:29 +0300 Subject: [address-policy-wg] =?utf-8?q?PA_=E2=80=93_life_after_death?= In-Reply-To: <69b2647c-a6a5-4985-857b-85d32afcf8e6@ukraine.su> References: <69b2647c-a6a5-4985-857b-85d32afcf8e6@ukraine.su> Message-ID: Everything is different in this universe ... Today we asked the RIPE NCC what will happen to our PI?s (assigned before we became LIR), in the event of SSA termination? The NCC?s answer was simple and concise, as always, I quote: ?The PI resources X.X.X.X and ASXXXXX are part of your LIR's infrastructure. According to the published procedure Closure of Members, Deregistration of Internet Resources and Legacy Internet Resources (https://www.ripe.net/publications/docs/ripe-697#b21) "The RIPE NCC will send an official notification by email to all registered contacts stating that the allocation/independent Internet number resources will be deregistered, explaining the reasons for this deregistration and the procedure of the deregistration." Therefore signing a Sponsoring contract with another LIR to support these resources is not possible.? -- Nikolay Gorstkin Tel: +7 (495) 517-4883 http://www.gcxc.net/ 140180, Zhukovskiy, Lomonosova 29a > 6 ????? 2019 ?., ? 20:24, Max Tulyev ???????(?): > > Hi Maxim, > > I remember that old good times when RIPE NCC was turned face to the community. > > That times in case of LIR closure assignments was converted to PI blocks and given directly to it's holders to avoid renumbering... > > 06.03.19 09:42, Maxim A Piskunov ????: >> Hi Guys! >> As I understand "NetUP Ltd." will loose their PA-addresses if LIR status will not recovered and customers will should renumbering their networks. >> I have one simple question: why not specified procedure of keeping originally allocated addresses for case when LIR-status under cancellation and LIR can't transfer PA to another LIR. >> Or I miss something and chance to keep addresses is exists? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stary.bezpiecznik at gmail.com Wed Mar 6 20:41:40 2019 From: stary.bezpiecznik at gmail.com (Stary Bezpiek) Date: Wed, 6 Mar 2019 20:41:40 +0100 Subject: [address-policy-wg] =?utf-8?q?PA_=E2=80=93_life_after_death?= In-Reply-To: References: <69b2647c-a6a5-4985-857b-85d32afcf8e6@ukraine.su> Message-ID: W dniu 06.03.2019 o?18:43, Nikolay Gorstkin pisze: > Everything is different in this universe ... Today we asked the RIPE > NCC what will happen to our PI?s (assigned before we became LIR), in > the event of SSA termination? > The NCC?s answer was simple and concise, as always, I quote: > > ?The PI resources X.X.X.X and ASXXXXX are part of your LIR's > infrastructure. > According to the published procedure Closure of Members, > Deregistration of Internet Resources and Legacy Internet Resources > (https://www.ripe.net/publications/docs/ripe-697#b21) > / > / > /"The RIPE NCC will send an official notification by email to all > registered contacts stating that the allocation/independent Internet > number resources will be deregistered, explaining the reasons for this > deregistration and the procedure of the deregistration."/ > > Therefore signing a Sponsoring contract with another LIR to support > these resources is not possible.? > > First of all - I'm dealing with RIPE and addresses about 20 years, and never heard, that PA from closed LIR going to be deregistered could be converted to PI. Years ago, when RIPE asked about PI to PA conversion, they promised, that in case of LIR closure, the member could preserve the PI. But... seems that is smallprint - you can keep the PI except you are self sponsor for the resource. The conclusion is: never convert the PI to PA and never move AS and PI to your own LIR, keep the sponsorship with third party. -- pl.skonet From it at gcxc.net Wed Mar 6 20:52:22 2019 From: it at gcxc.net (Nikolay Gorstkin) Date: Wed, 6 Mar 2019 22:52:22 +0300 Subject: [address-policy-wg] =?utf-8?q?PA_=E2=80=93_life_after_death?= In-Reply-To: References: <69b2647c-a6a5-4985-857b-85d32afcf8e6@ukraine.su> Message-ID: <6789123D-A42A-4AF3-86BD-18374378D8D7@gcxc.net> We did not convert to PA. But unfortunately they did not know that it was necessary to keep Sponsoring with a third party. -- Nikolay Gorstkin > 6 ????? 2019 ?., ? 22:41, Stary Bezpiek ???????(?): > > W dniu 06.03.2019 o 18:43, Nikolay Gorstkin pisze: >> Everything is different in this universe ... Today we asked the RIPE NCC what will happen to our PI?s (assigned before we became LIR), in the event of SSA termination? >> The NCC?s answer was simple and concise, as always, I quote: >> >> ?The PI resources X.X.X.X and ASXXXXX are part of your LIR's infrastructure. >> According to the published procedure Closure of Members, Deregistration of Internet Resources and Legacy Internet Resources (https://www.ripe.net/publications/docs/ripe-697#b21) >> / >> / >> /"The RIPE NCC will send an official notification by email to all registered contacts stating that the allocation/independent Internet number resources will be deregistered, explaining the reasons for this deregistration and the procedure of the deregistration."/ >> >> Therefore signing a Sponsoring contract with another LIR to support these resources is not possible.? >> >> > > First of all - I'm dealing with RIPE and addresses about 20 years, and never heard, that PA from closed LIR going to be deregistered could be converted to PI. > > Years ago, when RIPE asked about PI to PA conversion, they promised, that in case of LIR closure, the member could preserve the PI. But... seems that is smallprint - you can keep the PI except you are self sponsor for the resource. The conclusion is: never convert the PI to PA and never move AS and PI to your own LIR, keep the sponsorship with third party. > > -- > pl.skonet > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Wed Mar 6 21:10:20 2019 From: sander at steffann.nl (Sander Steffann) Date: Wed, 6 Mar 2019 21:10:20 +0100 Subject: [address-policy-wg] =?utf-8?q?PA_=E2=80=93_life_after_death?= In-Reply-To: <6789123D-A42A-4AF3-86BD-18374378D8D7@gcxc.net> References: <69b2647c-a6a5-4985-857b-85d32afcf8e6@ukraine.su> <6789123D-A42A-4AF3-86BD-18374378D8D7@gcxc.net> Message-ID: > We did not convert to PA. But unfortunately they did not know that it was necessary to keep Sponsoring with a third party. I'm a bit confused. What exactly are you doing? - Is the legal entity that was an LIR stopping? If the legal entity disappears then the resources go back to the NCC - Is the legal entity cancelling its RIPE NCC membership? In that case the resources can still be assigned to the legal entity and you should be able to find another sponsoring LIR - Did the NCC end the membership for violation of policies or non-payment? In that case: yes, you don't have any rights to those resources anymore - Something else? Without any mor information we're just guessing, which isn't very useful. I urge you to talk to the NCC to work this out, and if you can't work it out there is always the arbitration procedure... I don't think this is something that can be solved on APWG though. Full disclosure: I'm an arbiter on the NCC arbitration panel Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From gert at space.net Wed Mar 6 21:22:20 2019 From: gert at space.net (Gert Doering) Date: Wed, 6 Mar 2019 21:22:20 +0100 Subject: [address-policy-wg] PA ??? life after death In-Reply-To: References: Message-ID: <20190306202220.GM10407@Space.Net> Hi, On Wed, Mar 06, 2019 at 10:42:17AM +0300, Maxim A Piskunov wrote: > As I understand "NetUP Ltd." will loose their PA-addresses if LIR status > will not recovered and customers will should renumbering their networks. > I have one simple question: why not specified procedure of keeping > originally allocated addresses for case when LIR-status under cancellation > and LIR can't transfer PA to another LIR. > Or I miss something and chance to keep addresses is exists? If I can keep my addresses even if I do not fulfill my contractual obligations to the NCC ("pay my bill, do not lie, etc.") - why should I do that, then? Resources can only be kept while the LIR is not closed, and that will not happen unless there is good reason (usually: non-payment, lying to the NCC, or getting convicted of criminal activity). 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 it at gcxc.net Wed Mar 6 21:52:30 2019 From: it at gcxc.net (Nikolay Gorstkin) Date: Wed, 6 Mar 2019 23:52:30 +0300 Subject: [address-policy-wg] =?utf-8?q?PA_=E2=80=93_life_after_death?= In-Reply-To: References: <69b2647c-a6a5-4985-857b-85d32afcf8e6@ukraine.su> <6789123D-A42A-4AF3-86BD-18374378D8D7@gcxc.net> Message-ID: <66CF238B-B89D-4DDE-B2C3-DF6F1E0C6071@gcxc.net> Hi Sander I will try to explain briefly. > - Did the NCC end the membership for violation? Yes, the RIPE NCC is talking about violations, but we do not agree with that. We had no chance to prove our innocence. Recently, the RIPE NCC sent us - Official Notification of Termination. As they say they terminate the SSA in accordance with 9.4h. I will describe the details in the morning in the request for arbitration. Thank. -- Nikolay Gorstkin > 6 ????? 2019 ?., ? 23:10, Sander Steffann ???????(?): > >> We did not convert to PA. But unfortunately they did not know that it was necessary to keep Sponsoring with a third party. > > I'm a bit confused. What exactly are you doing? > > - Is the legal entity that was an LIR stopping? If the legal entity disappears then the resources go back to the NCC > - Is the legal entity cancelling its RIPE NCC membership? In that case the resources can still be assigned to the legal entity and you should be able to find another sponsoring LIR > - Did the NCC end the membership for violation of policies or non-payment? In that case: yes, you don't have any rights to those resources anymore > - Something else? > > Without any mor information we're just guessing, which isn't very useful. I urge you to talk to the NCC to work this out, and if you can't work it out there is always the arbitration procedure... I don't think this is something that can be solved on APWG though. > > Full disclosure: I'm an arbiter on the NCC arbitration panel > > Cheers, > Sander > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ffamax at gmail.com Wed Mar 6 21:53:10 2019 From: ffamax at gmail.com (Maxim A Piskunov) Date: Wed, 6 Mar 2019 23:53:10 +0300 Subject: [address-policy-wg] =?utf-8?q?PA_=E2=80=93_life_after_death?= In-Reply-To: References: <69b2647c-a6a5-4985-857b-85d32afcf8e6@ukraine.su> <6789123D-A42A-4AF3-86BD-18374378D8D7@gcxc.net> Message-ID: Hello, Sander! > - Did the NCC end the membership for violation of policies or non-payment? In that case: yes, you don't have any rights to those resources anymore It's like a blast on resource users and I believe that exactly new address policy can fix such situations. Even violation of policies happens resource users should not to keep responsibility for this. Resource users should continue use the same resources without renumbering. It's important possible impact for users. And i am ask for investigate current policy to find solution for users safety. On Wed, 6 Mar 2019 at 23:10, Sander Steffann wrote: > > We did not convert to PA. But unfortunately they did not know that it > was necessary to keep Sponsoring with a third party. > > I'm a bit confused. What exactly are you doing? > > - Is the legal entity that was an LIR stopping? If the legal entity > disappears then the resources go back to the NCC > - Is the legal entity cancelling its RIPE NCC membership? In that case the > resources can still be assigned to the legal entity and you should be able > to find another sponsoring LIR > - Did the NCC end the membership for violation of policies or non-payment? > In that case: yes, you don't have any rights to those resources anymore > - Something else? > > Without any mor information we're just guessing, which isn't very useful. > I urge you to talk to the NCC to work this out, and if you can't work it > out there is always the arbitration procedure... I don't think this is > something that can be solved on APWG though. > > Full disclosure: I'm an arbiter on the NCC arbitration panel > > Cheers, > Sander > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ffamax at gmail.com Wed Mar 6 22:04:04 2019 From: ffamax at gmail.com (Maxim A Piskunov) Date: Thu, 7 Mar 2019 00:04:04 +0300 Subject: [address-policy-wg] =?utf-8?q?PA_=E2=80=93_life_after_death?= In-Reply-To: <66CF238B-B89D-4DDE-B2C3-DF6F1E0C6071@gcxc.net> References: <69b2647c-a6a5-4985-857b-85d32afcf8e6@ukraine.su> <6789123D-A42A-4AF3-86BD-18374378D8D7@gcxc.net> <66CF238B-B89D-4DDE-B2C3-DF6F1E0C6071@gcxc.net> Message-ID: Thanks, Nikolay. Also I should append that for stability of Internet end-users should be in safety. It's mean that never-never-never resources can not be under stress if they currently in use! Part of that - RIPE NCC should not have a rights to terminate SSA without holding status for arbitration period. End-user SHOULD NOT PANIC. Official Notification of Termination - it's reason for panic. Of course, if we change policy for keeping used resources even LIR placed under termination procedure, happiness will come. On Wed, 6 Mar 2019 at 23:52, Nikolay Gorstkin wrote: > Hi Sander > > I will try to explain briefly. > > - Did the NCC end the membership for violation? > > Yes, the RIPE NCC is talking about violations, but we do not agree with > that. We had no chance to prove our innocence. > > Recently, the RIPE NCC sent us - Official Notification of Termination. As > they say they terminate the SSA in accordance with 9.4h. > I will describe the details in the morning in the request for arbitration. > > Thank. > > -- > *Nikolay Gorstkin* > > 6 ????? 2019 ?., ? 23:10, Sander Steffann ???????(?): > > We did not convert to PA. But unfortunately they did not know that it was > necessary to keep Sponsoring with a third party. > > > I'm a bit confused. What exactly are you doing? > > - Is the legal entity that was an LIR stopping? If the legal entity > disappears then the resources go back to the NCC > - Is the legal entity cancelling its RIPE NCC membership? In that case the > resources can still be assigned to the legal entity and you should be able > to find another sponsoring LIR > - Did the NCC end the membership for violation of policies or non-payment? > In that case: yes, you don't have any rights to those resources anymore > - Something else? > > Without any mor information we're just guessing, which isn't very useful. > I urge you to talk to the NCC to work this out, and if you can't work it > out there is always the arbitration procedure... I don't think this is > something that can be solved on APWG though. > > Full disclosure: I'm an arbiter on the NCC arbitration panel > > Cheers, > Sander > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ffamax at gmail.com Wed Mar 6 22:23:45 2019 From: ffamax at gmail.com (Maxim A Piskunov) Date: Thu, 7 Mar 2019 00:23:45 +0300 Subject: [address-policy-wg] PA ??? life after death In-Reply-To: <20190306202220.GM10407@Space.Net> References: <20190306202220.GM10407@Space.Net> Message-ID: Hello, Gert! LIR allocate from their PA some network to end-user. Even LIR will be closed, why end-user should lose allocated resources? What did end-user do wrong? Why end-user should lost allocated resources? As you wrote: "usually: (1) non-payment, (2) lying to the NCC, or (3) getting convicted of criminal activity" 1. End-user may initiate payment via temporary (substitutional) for allocated resources - it's not a reason for resources recall. 2.1 LIR lying to the NCC - ok. Close LIR but pass used resources to another LIR, why not? Who invented recall and for what? For pain? 2.2 End-user lying to LIR (but check passed) and as result LIR lying to NCC - yes, we can recall end-user resources, but only lying end-users. Not all resources of LIR. 3. Criminal activity should not impact end-users who did not do anything criminal. Current policy do not protect end-users. LIR - it's just like an administrator. We can fire administrator but current policy respectively destroy building where administrator has worked. On Wed, 6 Mar 2019 at 23:22, Gert Doering wrote: > Hi, > > On Wed, Mar 06, 2019 at 10:42:17AM +0300, Maxim A Piskunov wrote: > > As I understand "NetUP Ltd." will loose their PA-addresses if LIR status > > will not recovered and customers will should renumbering their networks. > > I have one simple question: why not specified procedure of keeping > > originally allocated addresses for case when LIR-status under > cancellation > > and LIR can't transfer PA to another LIR. > > Or I miss something and chance to keep addresses is exists? > > If I can keep my addresses even if I do not fulfill my contractual > obligations to the NCC ("pay my bill, do not lie, etc.") - why should > I do that, then? > > Resources can only be kept while the LIR is not closed, and that will > not happen unless there is good reason (usually: non-payment, lying > to the NCC, or getting convicted of criminal activity). > > 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 -------------- An HTML attachment was scrubbed... URL: From wusel+ml at uu.org Wed Mar 6 23:29:54 2019 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Wed, 6 Mar 2019 23:29:54 +0100 Subject: [address-policy-wg] PA ??? life after death In-Reply-To: References: <20190306202220.GM10407@Space.Net> Message-ID: <6ba93f2e-cbc5-6856-f82b-18cdd5ea4e98@uu.org> Moin, on 06.03.2019 22:23, Maxim A Piskunov wrote: > Current policy do not protect end-users. That's true; for one, that's the reason why there's this whole PI stuff, where End Users can ask for resources assigned directly to them. They need a sponsoring LIR, but in the event that LIR vanishes, a new can be choosen (given whois is kept accurate). Thus I see no need for any policy change. Regards, -kai From ffamax at gmail.com Wed Mar 6 23:40:32 2019 From: ffamax at gmail.com (Maxim A Piskunov) Date: Thu, 7 Mar 2019 01:40:32 +0300 Subject: [address-policy-wg] PA ??? life after death In-Reply-To: <6ba93f2e-cbc5-6856-f82b-18cdd5ea4e98@uu.org> References: <20190306202220.GM10407@Space.Net> <6ba93f2e-cbc5-6856-f82b-18cdd5ea4e98@uu.org> Message-ID: Hello, Kai! As I know, PI for IPv4 not possible to obtain for new users. One of chance - buy company with allocated PI. Another way - Allocate from LIR's PA. If member want to become BGP peer with routed IPv4 addresses he can use network from LIR's PA. But, this PA may be recalled when LIR will be closed. And no another way for end-user. One end least way for end-user - use PA and have risk of recall. As result PI can't help cuz PI can't be issued anymore. So time to change policy is coming. On Thu, 7 Mar 2019 at 01:30, Kai 'wusel' Siering wrote: > Moin, > > on 06.03.2019 22:23, Maxim A Piskunov wrote: > > Current policy do not protect end-users. > > That's true; for one, that's the reason why there's this whole PI stuff, > where End Users can ask for resources assigned directly to them. They need > a sponsoring LIR, but in the event that LIR vanishes, a new can be choosen > (given whois is kept accurate). > > Thus I see no need for any policy change. > > Regards, > -kai > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wusel+ml at uu.org Thu Mar 7 01:15:54 2019 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Thu, 7 Mar 2019 01:15:54 +0100 Subject: [address-policy-wg] PA ??? life after death In-Reply-To: References: <20190306202220.GM10407@Space.Net> <6ba93f2e-cbc5-6856-f82b-18cdd5ea4e98@uu.org> Message-ID: Moin, am 06.03.2019 um 23:40 schrieb Maxim A Piskunov: > Hello, Kai! > > As I know, PI for IPv4 not possible to obtain for new users. Sure; IPv4 is over, I strongly suggest to stop building business based on legacy technology. Having stated the obvoius, and correct me if I'm wrong, it is possible to buy IPv4 space these days, no? And if you really need save IPv4 space for your business, you're free to become an LIR, adhere to the policies, and be a happy camper. Regards, -kai From ffamax at gmail.com Thu Mar 7 06:59:52 2019 From: ffamax at gmail.com (Maxim A Piskunov) Date: Thu, 7 Mar 2019 08:59:52 +0300 Subject: [address-policy-wg] PA ??? life after death In-Reply-To: References: <20190306202220.GM10407@Space.Net> <6ba93f2e-cbc5-6856-f82b-18cdd5ea4e98@uu.org> Message-ID: Hi, Kai! We discuss last week and here some points of view. >And if you really need save IPv4 space for your business, you're free to become an LIR, adhere to the policies, and be a happy camper. 1. Some organisation will never become LIR (some institutes of government, etc) 2. Organization who prefer not to do cross-border payments (accounting issues) They coming and asking for addresses, LIR can allocate for example /24 from PA and next, if LIR will be closed, end-user may loose addressed It's happens because no procedures for protection such case. My position is to change policy for improving security for end-users. PI - it's safety for end-user. So why policy does not allow conversion PA to PI? Why PA addresses on closure LIR return to community pool instead keeping addresses for current end-user? Why policy still have no soft rules for this case? LIR closed -> resources converted to PI and passed to another LIR. It's a solution. >IPv4 is over, I strongly suggest to stop building business based on legacy technology IPv4 it's cheap and fast way to deploy network. IPv4 is over in pool but still available via LIR's, so please do not say that IPv4 is totally died. For places on Earth where no Internet connectivity, IPv4 coming first. And only when infrastructure is ready IPv6 may come. You trying to propagate IPv6 but you live in more ideal world and thinking from another point of view. I am not asking for propagation IPv6, I am asking for freely usage IPv4, for dropping not needed administrative obstacles. On Thu, 7 Mar 2019 at 03:16, Kai 'wusel' Siering wrote: > Moin, > > am 06.03.2019 um 23:40 schrieb Maxim A Piskunov: > > Hello, Kai! > > > > As I know, PI for IPv4 not possible to obtain for new users. > > Sure; IPv4 is over, I strongly suggest to stop building business based on > legacy technology. > > Having stated the obvoius, and correct me if I'm wrong, it is possible to > buy IPv4 space these days, no? And if you really need save IPv4 space for > your business, you're free to become an LIR, adhere to the policies, and be > a happy camper. > > Regards, > -kai > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominik at clouvider.co.uk Thu Mar 7 07:55:50 2019 From: dominik at clouvider.co.uk (Dominik Nowacki) Date: Thu, 7 Mar 2019 06:55:50 +0000 Subject: [address-policy-wg] PA ??? life after death In-Reply-To: References: <20190306202220.GM10407@Space.Net> <6ba93f2e-cbc5-6856-f82b-18cdd5ea4e98@uu.org> , Message-ID: <92EDE41D-440A-483C-B0CF-6DEE0FDA425B@clouvider.co.uk> Feel free to write and propose the policy to the community, but don?t get your hopes too high. I don?t believe there?s an appetite for changes in IPv4 policy world among membership. IPv4 is dead. Focus on deploying IPv6 where you can get a PI allocation. 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. On 7 Mar 2019, at 06:00, Maxim A Piskunov > wrote: Hi, Kai! We discuss last week and here some points of view. >And if you really need save IPv4 space for your business, you're free to become an LIR, adhere to the policies, and be a happy camper. 1. Some organisation will never become LIR (some institutes of government, etc) 2. Organization who prefer not to do cross-border payments (accounting issues) They coming and asking for addresses, LIR can allocate for example /24 from PA and next, if LIR will be closed, end-user may loose addressed It's happens because no procedures for protection such case. My position is to change policy for improving security for end-users. PI - it's safety for end-user. So why policy does not allow conversion PA to PI? Why PA addresses on closure LIR return to community pool instead keeping addresses for current end-user? Why policy still have no soft rules for this case? LIR closed -> resources converted to PI and passed to another LIR. It's a solution. >IPv4 is over, I strongly suggest to stop building business based on legacy technology IPv4 it's cheap and fast way to deploy network. IPv4 is over in pool but still available via LIR's, so please do not say that IPv4 is totally died. For places on Earth where no Internet connectivity, IPv4 coming first. And only when infrastructure is ready IPv6 may come. You trying to propagate IPv6 but you live in more ideal world and thinking from another point of view. I am not asking for propagation IPv6, I am asking for freely usage IPv4, for dropping not needed administrative obstacles. On Thu, 7 Mar 2019 at 03:16, Kai 'wusel' Siering > wrote: Moin, am 06.03.2019 um 23:40 schrieb Maxim A Piskunov: > Hello, Kai! > > As I know, PI for IPv4 not possible to obtain for new users. Sure; IPv4 is over, I strongly suggest to stop building business based on legacy technology. Having stated the obvoius, and correct me if I'm wrong, it is possible to buy IPv4 space these days, no? And if you really need save IPv4 space for your business, you're free to become an LIR, adhere to the policies, and be a happy camper. Regards, -kai -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe-wgs at radu-adrian.feurdean.net Thu Mar 7 14:21:40 2019 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Thu, 07 Mar 2019 08:21:40 -0500 Subject: [address-policy-wg] =?utf-8?q?PA_=E2=80=93_life_after_death?= In-Reply-To: <69b2647c-a6a5-4985-857b-85d32afcf8e6@ukraine.su> References: <69b2647c-a6a5-4985-857b-85d32afcf8e6@ukraine.su> Message-ID: <129d815d-a9bf-4a88-b590-36a55de7f357@www.fastmail.com> On Wed, Mar 6, 2019, at 18:23, Max Tulyev wrote: > I remember that old good times when RIPE NCC was turned face to the > community. > > That times in case of LIR closure assignments was converted to PI blocks > and given directly to it's holders to avoid renumbering... And how do you do that when assignments are smaller (prefix longer) than /24. What does a customer do with a /27 PI ? -- Radu-Adrian FEURDEAN From president at ukraine.su Thu Mar 7 15:23:26 2019 From: president at ukraine.su (Max Tulyev) Date: Thu, 7 Mar 2019 16:23:26 +0200 Subject: [address-policy-wg] PA ??? life after death In-Reply-To: <92EDE41D-440A-483C-B0CF-6DEE0FDA425B@clouvider.co.uk> References: <20190306202220.GM10407@Space.Net> <6ba93f2e-cbc5-6856-f82b-18cdd5ea4e98@uu.org> <92EDE41D-440A-483C-B0CF-6DEE0FDA425B@clouvider.co.uk> Message-ID: <41bbef05-5944-e673-0b15-52dcebcaa6ee@ukraine.su> Nice joke. 07.03.19 08:55, Dominik Nowacki ????: > IPv4 is dead. Focus on deploying IPv6 where you can get a PI allocation. From hunekm at gmail.com Fri Mar 8 13:19:28 2019 From: hunekm at gmail.com (Martin =?utf-8?B?SHVuxJtr?=) Date: Fri, 08 Mar 2019 13:19:28 +0100 Subject: [address-policy-wg] PA ??? life after death In-Reply-To: References: Message-ID: <2019084.3GHfbMEebd@hunator-ntb.local> Hi Maxim, I think that you are seeing just one side of the issue. I do not know details of your case, especially how the policies has been violated. But try for a moment to look at this from NCC perspective. If you would allow end-users of PA space to keep it as PI, then you would end up with lots of the /25+ prefixes in the DB. They would be either useless or someone had to aggregate them. Who would that be? The original LIR. It would continue the business as usual and it may even, as a bonus, run with less expanses (if it had just /22 - 200EUR annually instead of 1500). Now if you allow PA to PI conversion I think that there would be lots of LIRs doing precisely that. Converting its PA to PI, transferring it to another LIR and closing its own, cutting their expenses by factor of 10 (approx.). For the second mentioned problem, the transfer of blocked resources to another LIR: If you would as LIR lie to RIPE NCC and as a result you would get more resources or make let's say IPv6 PIs to ISPs. Then by allowing the transfer of such resources you would make it legitimate. Especially in the are of multi- LIR companies, closing ones LIR for policy violation would be a joke. If you are an end-user it might be unfair to you, but it is a risk of doing a business with a third party (connected with less expenses from your part). You may try to sue the LIR for not providing you services you have in your contract. If you are LIR which is being closed and you have broke the policy then it is fair and fully justified and it is on you to make sure end-users are not impacted by this. If you are LIR and did not brake the policy, then use arbitration to counter that. Long story short, PI in IPv4 is not coming back. We as community may change it in IPv6, but as someone already pointed out - no IPv4 policy is likely to pass in APWG. Also allowing transfer of resources which is being closed for policy violation would resulted in RIPE being defenseless against bad actors. Best Regards, Martin Post scriptum: IPv6 is not harder or slower to deploy than IPv4. If you would like to make IPv6-only network without transition mechanisms from scratch, it would be easier to make than IPv4-only. You wouldn't need CGN and also HA would be much easier (multiple routers on segment and so on). Technically the IPv6 should be faster, allows more freedom in network architecture and should require less logic in the network itself. It is mainly political problem, not technical. Dne ?tvrtek 7. b?ezna 2019 6:59:52 CET, Maxim A Piskunov napsal(a): > Hi, Kai! > > We discuss last week and here some points of view. > > >And if you really need save IPv4 space for your business, you're free to > > become an LIR, adhere to the policies, and be a happy camper. > 1. Some organisation will never become LIR (some institutes of government, > etc) > 2. Organization who prefer not to do cross-border payments (accounting > issues) > They coming and asking for addresses, LIR can allocate for example /24 from > PA and next, if LIR will be closed, end-user may loose addressed > It's happens because no procedures for protection such case. > > My position is to change policy for improving security for end-users. > PI - it's safety for end-user. So why policy does not allow conversion PA > to PI? > Why PA addresses on closure LIR return to community pool instead keeping > addresses for current end-user? Why policy still have no soft rules for > this case? LIR closed -> resources converted to PI and passed to another > LIR. It's a solution. > > >IPv4 is over, I strongly suggest to stop building business based on legacy > > technology > IPv4 it's cheap and fast way to deploy network. IPv4 is over in pool but > still available via LIR's, so please do not say that IPv4 is totally died. > For places on Earth where no Internet connectivity, IPv4 coming first. And > only when infrastructure is ready IPv6 may come. > You trying to propagate IPv6 but you live in more ideal world and thinking > from another point of view. > I am not asking for propagation IPv6, I am asking for freely usage IPv4, > for dropping not needed administrative obstacles. > > On Thu, 7 Mar 2019 at 03:16, Kai 'wusel' Siering wrote: > > Moin, > > > > am 06.03.2019 um 23:40 schrieb Maxim A Piskunov: > > > Hello, Kai! > > > > > > As I know, PI for IPv4 not possible to obtain for new users. > > > > Sure; IPv4 is over, I strongly suggest to stop building business based on > > legacy technology. > > > > Having stated the obvoius, and correct me if I'm wrong, it is possible to > > buy IPv4 space these days, no? And if you really need save IPv4 space for > > your business, you're free to become an LIR, adhere to the policies, and > > be > > a happy camper. > > > > Regards, > > -kai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From stary.bezpiecznik at gmail.com Fri Mar 8 14:02:34 2019 From: stary.bezpiecznik at gmail.com (Stary Bezpiek) Date: Fri, 8 Mar 2019 14:02:34 +0100 Subject: [address-policy-wg] PA ??? life after death In-Reply-To: <2019084.3GHfbMEebd@hunator-ntb.local> References: <2019084.3GHfbMEebd@hunator-ntb.local> Message-ID: <494f029a-95ad-48a0-2885-07a68383f509@gmail.com> W dniu 08.03.2019 o?13:19, Martin Hun?k pisze: > Post scriptum: IPv6 is not harder or slower to deploy than IPv4. If you would > like to make IPv6-only network without transition mechanisms from scratch, it > would be easier to make than IPv4-only. You wouldn't need CGN and also HA > would be much easier (multiple routers on segment and so on). Technically the > IPv6 should be faster, allows more freedom in network architecture and should > require less logic in the network itself. It is mainly political problem, not > technical. > Do not mix politics to IPv6, please. It's still lot of technical problems with IPv6 - the main one is dealing IPv6 by software (processors) instead of hardware. The first-hand example: Mikrotik. Lot of HW offload functions are only for IPv4. Same is with some Cisco's, or other randomly pointed devices. Amen. -- stary.bezpiek From hunekm at gmail.com Fri Mar 8 14:40:03 2019 From: hunekm at gmail.com (Martin =?utf-8?B?SHVuxJtr?=) Date: Fri, 08 Mar 2019 14:40:03 +0100 Subject: [address-policy-wg] PA ??? life after death In-Reply-To: <494f029a-95ad-48a0-2885-07a68383f509@gmail.com> References: <2019084.3GHfbMEebd@hunator-ntb.local> <494f029a-95ad-48a0-2885-07a68383f509@gmail.com> Message-ID: <3575012.qLd5TjnKZU@rumburak.ite.tul.cz> Not country/state politics. But inner politics of ISP or vendor. Those things mentioned by you are also more political then technical. When vendor chooses not to do HW offloading it is not because it would not be possible technically, but because vendor doesn't think it would be a such big issue. It might induce a technical issue for ISP, but it started as political one. Purely technical issue would be extension headers vs. HW based parsing, which makes it more demanding but still solvable. But from my experience, the most challenging thing is to convince executives to invest time/money into deployment of IPv6 - the politics. Anyway it is OT, so we might discuss it of APWG list. Martin Dne p?tek 8. b?ezna 2019 14:02:34 CET, Stary Bezpiek napsal(a): > W dniu 08.03.2019 o 13:19, Martin Hun?k pisze: > > Post scriptum: IPv6 is not harder or slower to deploy than IPv4. If you would > > like to make IPv6-only network without transition mechanisms from scratch, it > > would be easier to make than IPv4-only. You wouldn't need CGN and also HA > > would be much easier (multiple routers on segment and so on). Technically the > > IPv6 should be faster, allows more freedom in network architecture and should > > require less logic in the network itself. It is mainly political problem, not > > technical. > > > > Do not mix politics to IPv6, please. > > It's still lot of technical problems with IPv6 - the main one is dealing > IPv6 by software (processors) instead of hardware. > The first-hand example: Mikrotik. Lot of HW offload functions are only > for IPv4. Same is with some Cisco's, or other randomly pointed devices. > Amen. > > -------------- 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 dominik at clouvider.co.uk Fri Mar 8 14:45:42 2019 From: dominik at clouvider.co.uk (Dominik Nowacki) Date: Fri, 8 Mar 2019 13:45:42 +0000 Subject: [address-policy-wg] PA ??? life after death In-Reply-To: <494f029a-95ad-48a0-2885-07a68383f509@gmail.com> References: <2019084.3GHfbMEebd@hunator-ntb.local>, <494f029a-95ad-48a0-2885-07a68383f509@gmail.com> Message-ID: <682C9D7C-6A51-43C2-AE39-53A00A1F61FF@clouvider.co.uk> That?s only if you run on soho (Mikrotik) or prehistoric gear. It?s hard to find Cisco/Juniper Datacentre router manufactured in the last 5 years that wouldn?t have full support for IPv6. There?s absolutely zero reason not to deploy it yet! 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. On 8 Mar 2019, at 13:02, Stary Bezpiek > wrote: W dniu 08.03.2019 o 13:19, Martin Hun?k pisze: Post scriptum: IPv6 is not harder or slower to deploy than IPv4. If you would like to make IPv6-only network without transition mechanisms from scratch, it would be easier to make than IPv4-only. You wouldn't need CGN and also HA would be much easier (multiple routers on segment and so on). Technically the IPv6 should be faster, allows more freedom in network architecture and should require less logic in the network itself. It is mainly political problem, not technical. Do not mix politics to IPv6, please. It's still lot of technical problems with IPv6 - the main one is dealing IPv6 by software (processors) instead of hardware. The first-hand example: Mikrotik. Lot of HW offload functions are only for IPv4. Same is with some Cisco's, or other randomly pointed devices. Amen. -- stary.bezpiek -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Fri Mar 8 15:02:10 2019 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 08 Mar 2019 15:02:10 +0100 Subject: [address-policy-wg] PA ??? life after death In-Reply-To: <682C9D7C-6A51-43C2-AE39-53A00A1F61FF@clouvider.co.uk> References: <2019084.3GHfbMEebd@hunator-ntb.local> <494f029a-95ad-48a0-2885-07a68383f509@gmail.com> <682C9D7C-6A51-43C2-AE39-53A00A1F61FF@clouvider.co.uk> Message-ID: <0DBF7FFD-63C4-445B-8B3C-8E78F660296E@consulintel.es> Even very low-cost chipsets for CEs, such as Mediatek, Broadcom, Cavium/Marvell, etc., can offload IPv6 as well. Sometimes is not the hardware, but the firmware not taking advantage of it. For IPv6, unless you want pure dual-stack, not the right transition for what is needed now (IPv6-only with IPv4-as-a-Service), Mikrotik is the worst example, definitely. Regards, Jordi De: address-policy-wg en nombre de Dominik Nowacki Fecha: viernes, 8 de marzo de 2019, 14:45 Para: Stary Bezpiek CC: "address-policy-wg at ripe.net" Asunto: Re: [address-policy-wg] PA ??? life after death That?s only if you run on soho (Mikrotik) or prehistoric gear. It?s hard to find Cisco/Juniper Datacentre router manufactured in the last 5 years that wouldn?t have full support for IPv6. There?s absolutely zero reason not to deploy it yet! 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. On 8 Mar 2019, at 13:02, Stary Bezpiek wrote: W dniu 08.03.2019 o 13:19, Martin Hun?k pisze: Post scriptum: IPv6 is not harder or slower to deploy than IPv4. If you would like to make IPv6-only network without transition mechanisms from scratch, it would be easier to make than IPv4-only. You wouldn't need CGN and also HA would be much easier (multiple routers on segment and so on). Technically the IPv6 should be faster, allows more freedom in network architecture and should require less logic in the network itself. It is mainly political problem, not technical. Do not mix politics to IPv6, please. It's still lot of technical problems with IPv6 - the main one is dealing IPv6 by software (processors) instead of hardware. The first-hand example: Mikrotik. Lot of HW offload functions are only for IPv4. Same is with some Cisco's, or other randomly pointed devices. Amen. -- stary.bezpiek ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com 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 gert at space.net Fri Mar 8 21:15:48 2019 From: gert at space.net (Gert Doering) Date: Fri, 8 Mar 2019 21:15:48 +0100 Subject: [address-policy-wg] PA ??? life after death In-Reply-To: <494f029a-95ad-48a0-2885-07a68383f509@gmail.com> References: <2019084.3GHfbMEebd@hunator-ntb.local> <494f029a-95ad-48a0-2885-07a68383f509@gmail.com> Message-ID: <20190308201548.GS10407@Space.Net> Hi, On Fri, Mar 08, 2019 at 02:02:34PM +0100, Stary Bezpiek wrote: > It's still lot of technical problems with IPv6 - the main one is dealing > IPv6 by software (processors) instead of hardware. > The first-hand example: Mikrotik. Lot of HW offload functions are only > for IPv4. Same is with some Cisco's, or other randomly pointed devices. > Amen. I don't think anything built by Cisco in the last 10 years falls into the "IPv4 in hardware, IPv6 in software" category anymore. Maybe even 15 years. Instead of spreading outdated information, better spend the time working with those vendors that still ship broken implementations, or take your money elsewhere. If you look for excuses why you are not deploying IPv6, there will be plenty (see http://ipv6excuses.com). If you *want* to deploy, all the difficulties can be overcome - we've run IPv6 in production quality (= no performance penalty, fully monitored, etc.) since close to 20 years now. And yes, lots of obstacles in the beginning. 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 stary.bezpiecznik at gmail.com Fri Mar 8 21:44:43 2019 From: stary.bezpiecznik at gmail.com (Stary Bezpiek) Date: Fri, 8 Mar 2019 21:44:43 +0100 Subject: [address-policy-wg] PA ??? life after death In-Reply-To: <20190308201548.GS10407@Space.Net> References: <2019084.3GHfbMEebd@hunator-ntb.local> <494f029a-95ad-48a0-2885-07a68383f509@gmail.com> <20190308201548.GS10407@Space.Net> Message-ID: W dniu 08.03.2019 o?21:15, Gert Doering pisze: > I don't think anything built by Cisco in the last 10 years falls into the > "IPv4 in hardware, IPv6 in software" category anymore. Maybe even 15 years. > > Instead of spreading outdated information, better spend the time working > with those vendors that still ship broken implementations, or take your > money elsewhere. > > If you look for excuses why you are not deploying IPv6, there will be > plenty (see http://ipv6excuses.com). If you *want* to deploy, all > the difficulties can be overcome - we've run IPv6 in production > quality (= no performance penalty, fully monitored, etc.) since close > to 20 years now. And yes, lots of obstacles in the beginning. > > What is outdated? That Mikrotik deals V6 mostly in software? That Cisco 6800 series (still pretty wide used) is not ready to full support of today's IPv6 world? I don't know, where you got/found my alleged excuses about 'not deploy IPv6'. I'm letting you know, that my networks are IPv6 ready for many years, and the problem of using V6 in software is serious and your witchcraft and wishes will not change this. Your statement is polarity distant from good manners. Nothing justifies it. -- stary.bezpiek From max at rfc2324.org Sat Mar 9 18:07:39 2019 From: max at rfc2324.org (Maximilian Wilhelm) Date: Sat, 9 Mar 2019 18:07:39 +0100 Subject: [address-policy-wg] PA ??? life after death In-Reply-To: References: <2019084.3GHfbMEebd@hunator-ntb.local> <494f029a-95ad-48a0-2885-07a68383f509@gmail.com> <20190308201548.GS10407@Space.Net> Message-ID: <20190309170738.GA28250@principal.rfc2324.org> Anno domini 2019 Stary Bezpiek scripsit: Hi, [...] > What is outdated? That Mikrotik deals V6 mostly in software? That Cisco 6800 > series (still pretty wide used) is not ready to full support of today's IPv6 > world? Could you please elaborate on the shortcomings here? Best Max -- "really soon now": an unspecified period of time, likly to be greater than any reasonable definition of "soon". From stary.bezpiecznik at gmail.com Mon Mar 11 13:31:52 2019 From: stary.bezpiecznik at gmail.com (Stary Bezpiek) Date: Mon, 11 Mar 2019 13:31:52 +0100 Subject: [address-policy-wg] PA ??? life after death In-Reply-To: <20190309170738.GA28250@principal.rfc2324.org> References: <2019084.3GHfbMEebd@hunator-ntb.local> <494f029a-95ad-48a0-2885-07a68383f509@gmail.com> <20190308201548.GS10407@Space.Net> <20190309170738.GA28250@principal.rfc2324.org> Message-ID: <67b0e283-5599-a4dc-0c32-2e20b0e82898@gmail.com> W dniu 09.03.2019 o?18:07, Maximilian Wilhelm pisze: > Anno domini 2019 Stary Bezpiek scripsit: > > Hi, > > [...] >> What is outdated? That Mikrotik deals V6 mostly in software? That Cisco 6800 >> series (still pretty wide used) is not ready to full support of today's IPv6 >> world? > Could you please elaborate on the shortcomings here? > Mikrotik example: a) Take true 1Gig uplink to the internet b) take Mikrotik device with mipsbe processor, configure it to enable only V6 and perform a speedtest to the fast.com for example c) The same device enable v4 only and use HW offloads, fastpath, fasttrack and so on and perform the test from b) d) keep v4 only, disable HW offloads, fastpath fast track and perform the test e) compare results with a) f) try all above with PPPoE and compare My results: with v4 and all HW offload supports you can expect about 920 Mbps. With pure v6 - about 400 Mbps, same or even less with HW offloads disabled. Cisco: Cisco 6880-X - here we have no problems witch ipv4 and ipv6, but no 40G or bigger line cards. Only 10Gig cards is little to less in our IPv6 world. Cisco 6800 "legacy series" (quotes intended, hope you know what I mean) you have to observe combinations with "E" cassis to support appropriate supervisor avoiding ipv6 multicast limitations, 1M ipv4 prefixes limit with supervisors even XL, the 40Gig ports available only in 6807 SUP6T chassis of course with "E" SUP without XL only 128k ipv6 routes, and many others dependencies and complexities. I forgot about 6500/7600 series also still wide used - problem with shared FIB making it practically poor usable for v6, when you make place for v4 prefixes. Hope this helps. -- stary.bezpiek From mschmidt at ripe.net Mon Mar 11 13:37:47 2019 From: mschmidt at ripe.net (Marco Schmidt) Date: Mon, 11 Mar 2019 13:37:47 +0100 Subject: [address-policy-wg] 2019-01 Review Phase (Clarification of Definition for "ASSIGNED PA") Message-ID: Dear colleagues, Policy proposal 2019-01, "Clarification of Definition for "ASSIGNED PA"" is now in the Review Phase. This proposal aims to make it clear in the IPv4 Policy that the status "ASSIGNED PA" can also be used for assignments to an LIR's infrastructure. The RIPE NCC has prepared an impact analysis to support the community?s discussion. You can find the full proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2019-01 And the draft documents at: https://www.ripe.net/participate/policies/proposals/2019-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 9 April 2019. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From cfriacas at fccn.pt Mon Mar 11 17:25:25 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Mon, 11 Mar 2019 16:25:25 +0000 (WET) Subject: [address-policy-wg] 2019-01 Review Phase (Clarification of Definition for "ASSIGNED PA") In-Reply-To: References: Message-ID: Dear colleagues, After reading the Impact Analysis, i wish to express my support to 2019-01. Best Regards, Carlos Fria?as On Mon, 11 Mar 2019, Marco Schmidt wrote: > Dear colleagues, > > Policy proposal 2019-01, "Clarification of Definition for "ASSIGNED PA"" is now in the Review Phase. > > This proposal aims to make it clear in the IPv4 Policy that the status "ASSIGNED PA" can also be used for assignments to an LIR's infrastructure. > > The RIPE NCC has prepared an impact analysis to support the community?s discussion. You can find the full proposal and impact analysis at: > https://www.ripe.net/participate/policies/proposals/2019-01 > > And the draft documents at: > https://www.ripe.net/participate/policies/proposals/2019-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 9 April 2019. > > Kind regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > From zsako at iszt.hu Mon Mar 11 17:34:52 2019 From: zsako at iszt.hu (Janos Zsako) Date: Mon, 11 Mar 2019 17:34:52 +0100 Subject: [address-policy-wg] 2019-01 Review Phase (Clarification of Definition for "ASSIGNED PA") In-Reply-To: References: Message-ID: Dear all, > Policy proposal 2019-01, "Clarification of Definition for "ASSIGNED PA"" is now in the Review Phase. > > This proposal aims to make it clear in the IPv4 Policy that the status "ASSIGNED PA" can also be used for assignments to an LIR's infrastructure. As this reflects both the original intent and current practice, I support the proposal. Best regards, Janos > Marco Schmidt > Policy Development Officer From francis.brosnan at aspl.es Mon Mar 11 18:03:51 2019 From: francis.brosnan at aspl.es (Francis Brosnan =?ISO-8859-1?Q?Bl=E1zquez?=) Date: Mon, 11 Mar 2019 18:03:51 +0100 Subject: [address-policy-wg] 2019-01 Review Phase (Clarification of Definition for "ASSIGNED PA") In-Reply-To: References: Message-ID: <1552323831.3926.151.camel@aspl.es> Dear colleagues, This proposal makes sense to us. We support it. Best Regards. El lun, 11-03-2019 a las 16:25 +0000, Carlos Fria?as via address-policy-wg escribi?: > > Dear colleagues, > > After reading the Impact Analysis, i wish to express my support to > 2019-01. > > Best Regards, > Carlos Fria?as > > > On Mon, 11 Mar 2019, Marco Schmidt wrote: > > > Dear colleagues, > > > > Policy proposal 2019-01, "Clarification of Definition for "ASSIGNED PA"" is now in the Review Phase. > > > > This proposal aims to make it clear in the IPv4 Policy that the status "ASSIGNED PA" can also be used for assignments to an LIR's infrastructure. > > > > The RIPE NCC has prepared an impact analysis to support the community?s discussion. You can find the full proposal and impact analysis at: > > https://www.ripe.net/participate/policies/proposals/2019-01 > > > > And the draft documents at: > > https://www.ripe.net/participate/policies/proposals/2019-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 9 April 2019. > > > > Kind regards, > > > > Marco Schmidt > > Policy Development Officer > > RIPE NCC > > > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at prtsystems.ltd.uk Mon Mar 11 18:09:40 2019 From: paul at prtsystems.ltd.uk (Paul Thornton) Date: Mon, 11 Mar 2019 17:09:40 +0000 Subject: [address-policy-wg] 2019-01 Review Phase (Clarification of Definition for "ASSIGNED PA") In-Reply-To: References: Message-ID: <5C869654.6070802@prtsystems.ltd.uk> On 11/03/2019 12:37, Marco Schmidt wrote: > Dear colleagues, > > Policy proposal 2019-01, "Clarification of Definition for "ASSIGNED PA"" is now in the Review Phase. This proposal is just updating the documentation to better confirm what the intent - and actual application - of the policy is. This is a Good Thing. I support it. Paul. From me at cynthia.re Mon Mar 11 18:16:46 2019 From: me at cynthia.re (=?UTF-8?Q?Cynthia_Revstr=c3=b6m?=) Date: Mon, 11 Mar 2019 18:16:46 +0100 Subject: [address-policy-wg] 2019-01 Review Phase (Clarification of Definition for "ASSIGNED PA") In-Reply-To: References: Message-ID: <5a467aea-f853-3f7a-677e-d0fc55c9d017@cynthia.re> I support this proposal. I see nothing bad with it and it only clarifies things. - Cynthia On 2019-03-11 13:37, Marco Schmidt wrote: > Policy proposal 2019-01, "Clarification of Definition for "ASSIGNED PA"" is now in the Review Phase. From president at ukraine.su Mon Mar 11 21:01:04 2019 From: president at ukraine.su (Max Tulyev) Date: Mon, 11 Mar 2019 22:01:04 +0200 Subject: [address-policy-wg] 2019-01 Review Phase (Clarification of Definition for "ASSIGNED PA") In-Reply-To: References: Message-ID: Dear All, Sounds good. I support it. 11.03.19 14:37, Marco Schmidt ????: > Dear colleagues, > > Policy proposal 2019-01, "Clarification of Definition for "ASSIGNED PA"" is now in the Review Phase. > > This proposal aims to make it clear in the IPv4 Policy that the status "ASSIGNED PA" can also be used for assignments to an LIR's infrastructure. > > The RIPE NCC has prepared an impact analysis to support the community?s discussion. You can find the full proposal and impact analysis at: > https://www.ripe.net/participate/policies/proposals/2019-01 > > And the draft documents at: > https://www.ripe.net/participate/policies/proposals/2019-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 9 April 2019. > > Kind regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > > From cdh at nianet.dk Mon Mar 11 21:30:30 2019 From: cdh at nianet.dk (Christoffer Hansen) Date: Mon, 11 Mar 2019 20:30:30 +0000 Subject: [address-policy-wg] 2019-01 Review Phase (Clarification of Definition for "ASSIGNED PA") In-Reply-To: References: Message-ID: <9cf54fd9-b61a-bc2f-c140-c24ba9c130a5@nianet.dk> +1 Support the proposal. -- cdh at globalconnect.dk Globalconnect A/S | H?rsk?tten 3 | DK-2630 Taastrup https://www.globalconnect.dk | https://nianet.dk On 11/03/2019 13:37, Marco Schmidt wrote: > Policy proposal 2019-01, "Clarification of Definition for "ASSIGNED PA"" is now in the Review Phase. From herve.clement at orange.com Tue Mar 12 05:16:46 2019 From: herve.clement at orange.com (herve.clement at orange.com) Date: Tue, 12 Mar 2019 04:16:46 +0000 Subject: [address-policy-wg] 2019-01 Review Phase (Clarification of Definition for "ASSIGNED PA") In-Reply-To: <9cf54fd9-b61a-bc2f-c140-c24ba9c130a5@nianet.dk> References: <9cf54fd9-b61a-bc2f-c140-c24ba9c130a5@nianet.dk> Message-ID: <19332_1552364208_5C8732B0_19332_366_1_2AF4C0655C93DD4D9A005252D465A808686D8E74@OPEXCAUBM43.corporate.adroot.infra.ftgroup> +1 Herv? CLEMENT -----Message d'origine----- De?: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] De la part de Christoffer Hansen Envoy??: lundi 11 mars 2019 21:31 ??: address-policy-wg at ripe.net Objet?: Re: [address-policy-wg] 2019-01 Review Phase (Clarification of Definition for "ASSIGNED PA") +1 Support the proposal. -- cdh at globalconnect.dk Globalconnect A/S | H?rsk?tten 3 | DK-2630 Taastrup https://www.globalconnect.dk | https://nianet.dk On 11/03/2019 13:37, Marco Schmidt wrote: > Policy proposal 2019-01, "Clarification of Definition for "ASSIGNED PA"" is now in the Review Phase. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From tore at fud.no Tue Mar 12 12:32:32 2019 From: tore at fud.no (Tore Anderson) Date: Tue, 12 Mar 2019 12:32:32 +0100 Subject: [address-policy-wg] 2019-01 Review Phase (Clarification of Definition for "ASSIGNED PA") In-Reply-To: References: Message-ID: * Marco Schmidt > Policy proposal 2019-01, "Clarification of Definition for "ASSIGNED PA"" is now in the Review Phase. Supported. Tore From mschmidt at ripe.net Tue Mar 12 13:45:25 2019 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 12 Mar 2019 13:45:25 +0100 Subject: [address-policy-wg] 2018-02 Policy Proposal Withdrawn (Assignment Clarification in IPv6 Policy) Message-ID: Dear colleagues, The policy proposal 2018-02, "Assignment Clarification in IPv6 Policy" has been withdrawn. This proposal aimed to clarify the definition of "Assign" in the IPv6 Policy (section 2.6). The proposal is archived and can be found at: https://www.ripe.net/participate/policies/archived-policy-proposals/archive-policy-proposals/ Reason for withdrawal: The proposer decided it was best to find agreement on a problem statement before developing new policy text. 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 Tue Mar 12 13:57:14 2019 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Tue, 12 Mar 2019 08:57:14 -0400 Subject: [address-policy-wg] =?utf-8?q?2019-01_Review_Phase_=28Clarificat?= =?utf-8?q?ion_of_Definition_for_=22ASSIGNED_PA=22=29?= In-Reply-To: <19332_1552364208_5C8732B0_19332_366_1_2AF4C0655C93DD4D9A005252D465A808686D8E74@OPEXCAUBM43.corporate.adroot.infra.ftgroup> References: <9cf54fd9-b61a-bc2f-c140-c24ba9c130a5@nianet.dk> <19332_1552364208_5C8732B0_19332_366_1_2AF4C0655C93DD4D9A005252D465A808686D8E74@OPEXCAUBM43.corporate.adroot.infra.ftgroup> Message-ID: <4fe64008-d46f-467f-b69b-1cf01c664886@www.fastmail.com> Support here too. -- Radu-Adrian FEURDEAN From sebastian at karotte.org Tue Mar 12 17:25:34 2019 From: sebastian at karotte.org (Sebastian Wiesinger) Date: Tue, 12 Mar 2019 17:25:34 +0100 Subject: [address-policy-wg] 2019-01 Review Phase (Clarification of Definition for "ASSIGNED PA") In-Reply-To: References: Message-ID: <20190312162534.5k7wyh36uygippol@danton.fire-world.de> * Marco Schmidt [2019-03-11 13:38]: > Dear colleagues, > > Policy proposal 2019-01, "Clarification of Definition for "ASSIGNED PA"" is now in the Review Phase. I support this. Regards Sebastian -- GPG Key: 0x58A2D94A93A0B9CE (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 ffamax at gmail.com Tue Mar 12 18:47:49 2019 From: ffamax at gmail.com (Maxim A Piskunov) Date: Tue, 12 Mar 2019 20:47:49 +0300 Subject: [address-policy-wg] PA ??? life after death In-Reply-To: <2019084.3GHfbMEebd@hunator-ntb.local> References: <2019084.3GHfbMEebd@hunator-ntb.local> Message-ID: Hello, Marting, Members. >Long story short, PI in IPv4 is not coming back. We as community may change it >in IPv6, but as someone already pointed out - no IPv4 policy is likely to pass >in APWG. Also allowing transfer of resources which is being closed for policy >violation would resulted in RIPE being defenseless against bad actors. Please explain anybody, "PI in IPv4 is not coming back" -- is any rules what prohibit community to turn situation to allow PA to PI conversion for use by end-user purposes? Example: LIR got /22 PA, LIR convert /22 to /23 PA + /24 PA + /24 PI and last /24 PI provide (move/transfer) to end-user. Why not? In this case end-user will be in safety even LIR gone. On Fri, 8 Mar 2019 at 15:19, Martin Hun?k wrote: > Hi Maxim, > > I think that you are seeing just one side of the issue. > > I do not know details of your case, especially how the policies has been > violated. > > But try for a moment to look at this from NCC perspective. If you would > allow > end-users of PA space to keep it as PI, then you would end up with lots of > the > /25+ prefixes in the DB. They would be either useless or someone had to > aggregate them. Who would that be? The original LIR. It would continue the > business as usual and it may even, as a bonus, run with less expanses (if > it > had just /22 - 200EUR annually instead of 1500). > > Now if you allow PA to PI conversion I think that there would be lots of > LIRs > doing precisely that. Converting its PA to PI, transferring it to another > LIR > and closing its own, cutting their expenses by factor of 10 (approx.). > > For the second mentioned problem, the transfer of blocked resources to > another > LIR: If you would as LIR lie to RIPE NCC and as a result you would get > more > resources or make let's say IPv6 PIs to ISPs. Then by allowing the > transfer of > such resources you would make it legitimate. Especially in the are of > multi- > LIR companies, closing ones LIR for policy violation would be a joke. > > If you are an end-user it might be unfair to you, but it is a risk of > doing a > business with a third party (connected with less expenses from your part). > You > may try to sue the LIR for not providing you services you have in your > contract. > > If you are LIR which is being closed and you have broke the policy then it > is > fair and fully justified and it is on you to make sure end-users are not > impacted by this. > > If you are LIR and did not brake the policy, then use arbitration to > counter > that. > > Long story short, PI in IPv4 is not coming back. We as community may > change it > in IPv6, but as someone already pointed out - no IPv4 policy is likely to > pass > in APWG. Also allowing transfer of resources which is being closed for > policy > violation would resulted in RIPE being defenseless against bad actors. > > Best Regards, > Martin > > Post scriptum: IPv6 is not harder or slower to deploy than IPv4. If you > would > like to make IPv6-only network without transition mechanisms from scratch, > it > would be easier to make than IPv4-only. You wouldn't need CGN and also HA > would be much easier (multiple routers on segment and so on). Technically > the > IPv6 should be faster, allows more freedom in network architecture and > should > require less logic in the network itself. It is mainly political problem, > not > technical. > > Dne ?tvrtek 7. b?ezna 2019 6:59:52 CET, Maxim A Piskunov napsal(a): > > Hi, Kai! > > > > We discuss last week and here some points of view. > > > > >And if you really need save IPv4 space for your business, you're free to > > > > become an LIR, adhere to the policies, and be a happy camper. > > 1. Some organisation will never become LIR (some institutes of > government, > > etc) > > 2. Organization who prefer not to do cross-border payments (accounting > > issues) > > They coming and asking for addresses, LIR can allocate for example /24 > from > > PA and next, if LIR will be closed, end-user may loose addressed > > It's happens because no procedures for protection such case. > > > > My position is to change policy for improving security for end-users. > > PI - it's safety for end-user. So why policy does not allow conversion PA > > to PI? > > Why PA addresses on closure LIR return to community pool instead keeping > > addresses for current end-user? Why policy still have no soft rules for > > this case? LIR closed -> resources converted to PI and passed to another > > LIR. It's a solution. > > > > >IPv4 is over, I strongly suggest to stop building business based on > legacy > > > > technology > > IPv4 it's cheap and fast way to deploy network. IPv4 is over in pool but > > still available via LIR's, so please do not say that IPv4 is totally > died. > > For places on Earth where no Internet connectivity, IPv4 coming first. > And > > only when infrastructure is ready IPv6 may come. > > You trying to propagate IPv6 but you live in more ideal world and > thinking > > from another point of view. > > I am not asking for propagation IPv6, I am asking for freely usage IPv4, > > for dropping not needed administrative obstacles. > > > > On Thu, 7 Mar 2019 at 03:16, Kai 'wusel' Siering > wrote: > > > Moin, > > > > > > am 06.03.2019 um 23:40 schrieb Maxim A Piskunov: > > > > Hello, Kai! > > > > > > > > As I know, PI for IPv4 not possible to obtain for new users. > > > > > > Sure; IPv4 is over, I strongly suggest to stop building business based > on > > > legacy technology. > > > > > > Having stated the obvoius, and correct me if I'm wrong, it is possible > to > > > buy IPv4 space these days, no? And if you really need save IPv4 space > for > > > your business, you're free to become an LIR, adhere to the policies, > and > > > be > > > a happy camper. > > > > > > Regards, > > > -kai > > -----BEGIN PGP SIGNATURE----- > > iQEzBAABCAAdFiEEDTFPGJgWyk/BQ0/gtRBl6lEd5VwFAlyCXdAACgkQtRBl6lEd > 5Vwy6wf+LT48qoMsNTPL/P+l0m+TmgpWHDffyDsBrImnQUQh0v4L6jkZUYt2bMjd > bYeRnsG8TEg+Gsv5fwgQf/m2sVpO6yNou+7GTkoZxFC7BNRh43al+ErXXGL+qTJX > cqG/yFgoYVlAY9BJKvKNdBT0l9SuBAZu8XwiAMGV6VaRjcgNgSXwy2VPULBDF42L > AN4lh3/Vh0uRWKFZDcTMOdIBFhIbgKWBhkp5DzDtT8+kCp6uTvD8jyd4+q6Mp7tZ > mCiIgJ5UMUR7wXFcevOuVi8Zm90Bd3FoRHftr8uccDryVykHpd8aNR5lD53vkFGA > X/slznIMMn4qPShubXISIxv+5O2gEA== > =7ett > -----END PGP SIGNATURE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ffamax at gmail.com Tue Mar 12 18:58:43 2019 From: ffamax at gmail.com (Maxim A Piskunov) Date: Tue, 12 Mar 2019 20:58:43 +0300 Subject: [address-policy-wg] PA ??? life after death In-Reply-To: <3575012.qLd5TjnKZU@rumburak.ite.tul.cz> References: <2019084.3GHfbMEebd@hunator-ntb.local> <494f029a-95ad-48a0-2885-07a68383f509@gmail.com> <3575012.qLd5TjnKZU@rumburak.ite.tul.cz> Message-ID: > Do not mix politics to IPv6, please. +1 > Not country/state politics. But inner politics of ISP or vendor. Martin, I know my case and I have no IPv6 uplink at few locations, and my users have no any Internet, even via cellular network. So please, it's not about IPv6 as "extension", it's about basic network on minimal resources where IPv6 is not possible. Cave people want to eat, please do not tell them that they should eat only organic food. Let them just eat what they have or they will die. On Fri, 8 Mar 2019 at 16:40, Martin Hun?k wrote: > Not country/state politics. But inner politics of ISP or vendor. > > Those things mentioned by you are also more political then technical. When > vendor chooses not to do HW offloading it is not because it would not be > possible technically, but because vendor doesn't think it would be a such > big issue. It might induce a technical issue for ISP, but it started as > political one. > > Purely technical issue would be extension headers vs. HW based parsing, > which makes it more demanding but still solvable. > > But from my experience, the most challenging thing is to convince > executives to invest time/money into deployment of IPv6 - the politics. > > Anyway it is OT, so we might discuss it of APWG list. > > Martin > > Dne p?tek 8. b?ezna 2019 14:02:34 CET, Stary Bezpiek napsal(a): > > W dniu 08.03.2019 o 13:19, Martin Hun?k pisze: > > > Post scriptum: IPv6 is not harder or slower to deploy than IPv4. If > you would > > > like to make IPv6-only network without transition mechanisms from > scratch, it > > > would be easier to make than IPv4-only. You wouldn't need CGN and also > HA > > > would be much easier (multiple routers on segment and so on). > Technically the > > > IPv6 should be faster, allows more freedom in network architecture and > should > > > require less logic in the network itself. It is mainly political > problem, not > > > technical. > > > > > > > Do not mix politics to IPv6, please. > > > > It's still lot of technical problems with IPv6 - the main one is dealing > > IPv6 by software (processors) instead of hardware. > > The first-hand example: Mikrotik. Lot of HW offload functions are only > > for IPv4. Same is with some Cisco's, or other randomly pointed devices. > > Amen. > > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQEcBAABCAAGBQJcgnC3AAoJELUQZepRHeVc2wQIANnSOlGBV9ZwgG/3/oJam5Oe > bhOwiSlOxt3kPQh4mYCkPbi9V3HPnXdnOej/MTHv1bei7cKNYdz+7ey9mBNj31Dh > HiZjLrh1pLfBhw0oMXJ38lmmkn0jTyrOWHVEXwcSIj7oYUk6QhAh6RVideHjL319 > W04+99uRkrxy8fVQLd3iN9kYIaHUXAR/zakOw/tbbmvNiSHkmnoyEx2w706NtWr8 > 97XsJ8w3XEdQHKb4jF8GrxcIZTCwE3VJ0+l6laOYoPSU5FAHur3PqhyWjxd5IrkD > 8DnDr+53Y1N+oO/sExmEutXXertWjqiKPaSQopUIn4+p02GrL9oDCUFhOZChb+o= > =N2iw > -----END PGP SIGNATURE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ffamax at gmail.com Tue Mar 12 19:16:02 2019 From: ffamax at gmail.com (Maxim A Piskunov) Date: Tue, 12 Mar 2019 21:16:02 +0300 Subject: [address-policy-wg] PA ??? life after death In-Reply-To: <20190308201548.GS10407@Space.Net> References: <2019084.3GHfbMEebd@hunator-ntb.local> <494f029a-95ad-48a0-2885-07a68383f509@gmail.com> <20190308201548.GS10407@Space.Net> Message-ID: Hello, Gert, Community. IPv4 - it's not outdated, exact about IPv4 we are talking. Not about IPv6. And we discuss way to continue support and effective use IPv4 while IPv4 will be not needed anymore. And while we still need IPv4 I wake up members to solve issues: 1. End-user should have independence of LIR 2. Independence of LIR may be obtained by conversion PA to PI and passing addresses to end-user. (/24 or greatest). 3. Even end-user using address from PA and address block /24 or greatest, we should change policy to allow conversion PA to PI for allocated to end-user's addresses if LIR placed under deregistration procedure. Community, please support my proposals. >I don't think anything built by Cisco in the last 10 years falls into the >"IPv4 in hardware, IPv6 in software" category anymore. Maybe even 15 years. > >Instead of spreading outdated information, better spend the time working >with those vendors that still ship broken implementations, or take your >money elsewhere. -------------- next part -------------- An HTML attachment was scrubbed... URL: From radu.anghel at xindi.ro Tue Mar 12 20:25:18 2019 From: radu.anghel at xindi.ro (Radu Anghel) Date: Tue, 12 Mar 2019 21:25:18 +0200 Subject: [address-policy-wg] 2019-01 Review Phase (Clarification of Definition for "ASSIGNED PA") In-Reply-To: References: Message-ID: On 11.03.2019 18:34, Janos Zsako wrote: > Dear all, > >> Policy proposal 2019-01, "Clarification of Definition for "ASSIGNED >> PA"" is now in the Review Phase. >> >> This proposal aims to make it clear in the IPv4 Policy that the status >> "ASSIGNED PA" can also be used for assignments to an LIR's >> infrastructure. > > As this reflects both the original intent and current practice, I > support the > proposal. > > Best regards, > Janos > +1 From cfriacas at fccn.pt Tue Mar 12 22:29:24 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Tue, 12 Mar 2019 21:29:24 +0000 (WET) Subject: [address-policy-wg] PA ??? life after death In-Reply-To: References: <2019084.3GHfbMEebd@hunator-ntb.local> <494f029a-95ad-48a0-2885-07a68383f509@gmail.com> <20190308201548.GS10407@Space.Net> Message-ID: On Tue, 12 Mar 2019, Maxim A Piskunov wrote: > Hello, Gert, Community. Hi, > IPv4 - it's not outdated, exact about IPv4 we are talking. Not about IPv6. > And we discuss way to continue support and effective use IPv4 while IPv4 will be not needed anymore. Yes, IPv4 is still the dominant Internet Protocol version. > And while we still need IPv4 I wake up members to solve issues: > 1. End-user should have independence of LIR > 2. Independence of LIR may be obtained by conversion PA to PI and passing addresses to end-user. (/24 or greatest). > 3. Even end-user using address from PA and address block /24 or greatest, we should change policy to allow conversion PA to PI for allocated to end-user's addresses if LIR placed under deregistration procedure. Independence of LIR can be obtained by an end-user by... becoming a LIR itself...! > Community, please support my proposals. It's not as simple as that... :-) The process is defined here... https://www.ripe.net/publications/docs/ripe-710 As of today, there are 3 proposals on the table: https://www.ripe.net/participate/policies/current-proposals/ 2018-06 RIPE NCC IRR Database Non-Authoritative Route Object Clean-up 2019-01 Clarification of Definition for "ASSIGNED PA" 2019-02 Reducing IPv4 Allocations to a /24 Regards, Carlos > >I don't think anything built by Cisco in the last 10 years falls into the > >"IPv4 in hardware, IPv6 in software" category anymore.? Maybe even 15 years. > > > >Instead of spreading outdated information, better spend the time working > >with those vendors that still ship broken implementations, or take your > >money elsewhere. > > From burstaoe at gmail.com Wed Mar 13 10:12:23 2019 From: burstaoe at gmail.com (Vitaliy joness) Date: Wed, 13 Mar 2019 10:12:23 +0100 Subject: [address-policy-wg] =?utf-8?q?PA_=E2=80=93_life_after_death?= In-Reply-To: Message-ID: hmmm thats helps me Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From wusel+ml at uu.org Wed Mar 13 14:02:56 2019 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Wed, 13 Mar 2019 14:02:56 +0100 Subject: [address-policy-wg] PA ??? life after death In-Reply-To: References: <2019084.3GHfbMEebd@hunator-ntb.local> <494f029a-95ad-48a0-2885-07a68383f509@gmail.com> <20190308201548.GS10407@Space.Net> Message-ID: <108352f2-b3f9-1ae8-bc6c-72621cd98039@uu.org> Hi, on 12.03.2019 19:16, Maxim A Piskunov wrote: > Hello, Gert, Community. > > IPv4 - it's not outdated, exact about IPv4 we are talking. Not about IPv6. IPv4 address space has been used up already, just accept the facts. > And while we still need IPv4 I wake up members to solve issues: > 1. End-user should have independence of LIR You're 20 years late. There are no resources in IPv4 to support this anymore, therefore it's buy IPv4 space (on a market that shouldn't be there in the first place) or become an LIR (better hurry, IPv4 number resources are scarce already) or prepare to renumber in case of LIR closure. > 2. Independence of LIR may be obtained by conversion PA to PI and passing addresses to end-user. (/24 or greatest). Technically, that's true. Feel free to send a proposal according to RIPE's PDP. > 3. Even end-user using address from PA and address block /24 or greatest, we should change policy to allow conversion PA to PI for allocated to end-user's addresses if LIR placed under deregistration procedure. For already stated reasons I do not think that's a way to move forward, but anyone may supply any proposal via the PDP to discuss it within the RIPE Community. > Community, please support my proposals. I do not see any chance for this in this timeline, but am looking forward to discuss it, once a formal proposal exists. Regards, -kai From hunekm at gmail.com Wed Mar 13 14:29:02 2019 From: hunekm at gmail.com (Martin =?utf-8?B?SHVuxJtr?=) Date: Wed, 13 Mar 2019 14:29:02 +0100 Subject: [address-policy-wg] PA ??? life after death In-Reply-To: References: <2019084.3GHfbMEebd@hunator-ntb.local> Message-ID: <2257052.xcAic4ZSXB@rumburak.ite.tul.cz> Hi Maxim, reply inline. Dne ?ter? 12. b?ezna 2019 18:47:49 CET jste napsal(a): > Hello, Marting, Members. > > >Long story short, PI in IPv4 is not coming back. We as community may > >change it > >in IPv6, but as someone already pointed out - no IPv4 policy is likely to > >pass > >in APWG. Also allowing transfer of resources which is being closed for > >policy > >violation would resulted in RIPE being defenseless against bad actors. > > Please explain anybody, "PI in IPv4 is not coming back" -- is any rules > what prohibit community to turn situation to allow PA to PI conversion for > use by end-user purposes? > Example: LIR got /22 PA, LIR convert /22 to /23 PA + /24 PA + /24 PI and > last /24 PI provide (move/transfer) to end-user. Why not? In this case > end-user will be in safety even LIR gone. It is not a rule, however by observing IPv4 related proposals in APWG as they reached dead end by not reaching consensus, it seem so. When you combine the fact that current policy doesn't allow PA to PI conversions and assignment of PI is given only to IXP, with low probability of successful IPv4 policy change. Then in my opinion "PI in IPv4 is not coming back". My impression is that here are essentially two extremes towards IPv4: One group would like to gave IPv4 out as fast as possible, the second one would like to conserve it as long as possible. With most people standing somewhere between these two but closer to the edge or those extremes been more vocal. Thing is, that both groups have valid points and are following different agenda. Because of this it might be quite difficult to have consensus on anything which at least smells by moving balance to either side. I might be a bit negativistic, but I think that it would be quite hard as long as either group would have something to gain. And for why not? For me: Mainly risk of further deaggregation, risk of opening loophole for bad actors and risk of massive exodus of LIRs which would gain sufficient safety so they would not need to be LIR anymore. By the way there was a proposal to allow PI assignments from last /8 which was withdrawn in 2013: https://www.ripe.net/participate/policies/proposals/2012-04 Martin > On Fri, 8 Mar 2019 at 15:19, Martin Hun?k wrote: > > > Hi Maxim, > > > > I think that you are seeing just one side of the issue. > > > > I do not know details of your case, especially how the policies has been > > violated. > > > > But try for a moment to look at this from NCC perspective. If you would > > allow > > end-users of PA space to keep it as PI, then you would end up with lots of > > the > > /25+ prefixes in the DB. They would be either useless or someone had to > > aggregate them. Who would that be? The original LIR. It would continue the > > business as usual and it may even, as a bonus, run with less expanses (if > > it > > had just /22 - 200EUR annually instead of 1500). > > > > Now if you allow PA to PI conversion I think that there would be lots of > > LIRs > > doing precisely that. Converting its PA to PI, transferring it to another > > LIR > > and closing its own, cutting their expenses by factor of 10 (approx.). > > > > For the second mentioned problem, the transfer of blocked resources to > > another > > LIR: If you would as LIR lie to RIPE NCC and as a result you would get > > more > > resources or make let's say IPv6 PIs to ISPs. Then by allowing the > > transfer of > > such resources you would make it legitimate. Especially in the are of > > multi- > > LIR companies, closing ones LIR for policy violation would be a joke. > > > > If you are an end-user it might be unfair to you, but it is a risk of > > doing a > > business with a third party (connected with less expenses from your part). > > You > > may try to sue the LIR for not providing you services you have in your > > contract. > > > > If you are LIR which is being closed and you have broke the policy then it > > is > > fair and fully justified and it is on you to make sure end-users are not > > impacted by this. > > > > If you are LIR and did not brake the policy, then use arbitration to > > counter > > that. > > > > Long story short, PI in IPv4 is not coming back. We as community may > > change it > > in IPv6, but as someone already pointed out - no IPv4 policy is likely to > > pass > > in APWG. Also allowing transfer of resources which is being closed for > > policy > > violation would resulted in RIPE being defenseless against bad actors. > > > > Best Regards, > > Martin > > > > Post scriptum: IPv6 is not harder or slower to deploy than IPv4. If you > > would > > like to make IPv6-only network without transition mechanisms from scratch, > > it > > would be easier to make than IPv4-only. You wouldn't need CGN and also HA > > would be much easier (multiple routers on segment and so on). Technically > > the > > IPv6 should be faster, allows more freedom in network architecture and > > should > > require less logic in the network itself. It is mainly political problem, > > not > > technical. > > > > Dne ?tvrtek 7. b?ezna 2019 6:59:52 CET, Maxim A Piskunov napsal(a): > > > Hi, Kai! > > > > > > We discuss last week and here some points of view. > > > > > > >And if you really need save IPv4 space for your business, you're free to > > > > > > become an LIR, adhere to the policies, and be a happy camper. > > > 1. Some organisation will never become LIR (some institutes of > > government, > > > etc) > > > 2. Organization who prefer not to do cross-border payments (accounting > > > issues) > > > They coming and asking for addresses, LIR can allocate for example /24 > > from > > > PA and next, if LIR will be closed, end-user may loose addressed > > > It's happens because no procedures for protection such case. > > > > > > My position is to change policy for improving security for end-users. > > > PI - it's safety for end-user. So why policy does not allow conversion PA > > > to PI? > > > Why PA addresses on closure LIR return to community pool instead keeping > > > addresses for current end-user? Why policy still have no soft rules for > > > this case? LIR closed -> resources converted to PI and passed to another > > > LIR. It's a solution. > > > > > > >IPv4 is over, I strongly suggest to stop building business based on > > legacy > > > > > > technology > > > IPv4 it's cheap and fast way to deploy network. IPv4 is over in pool but > > > still available via LIR's, so please do not say that IPv4 is totally > > died. > > > For places on Earth where no Internet connectivity, IPv4 coming first. > > And > > > only when infrastructure is ready IPv6 may come. > > > You trying to propagate IPv6 but you live in more ideal world and > > thinking > > > from another point of view. > > > I am not asking for propagation IPv6, I am asking for freely usage IPv4, > > > for dropping not needed administrative obstacles. > > > > > > On Thu, 7 Mar 2019 at 03:16, Kai 'wusel' Siering > > wrote: > > > > Moin, > > > > > > > > am 06.03.2019 um 23:40 schrieb Maxim A Piskunov: > > > > > Hello, Kai! > > > > > > > > > > As I know, PI for IPv4 not possible to obtain for new users. > > > > > > > > Sure; IPv4 is over, I strongly suggest to stop building business based > > on > > > > legacy technology. > > > > > > > > Having stated the obvoius, and correct me if I'm wrong, it is possible > > to > > > > buy IPv4 space these days, no? And if you really need save IPv4 space > > for > > > > your business, you're free to become an LIR, adhere to the policies, > > and > > > > be > > > > a happy camper. > > > > > > > > Regards, > > > > -kai > > > > -----BEGIN PGP SIGNATURE----- > > > > iQEzBAABCAAdFiEEDTFPGJgWyk/BQ0/gtRBl6lEd5VwFAlyCXdAACgkQtRBl6lEd > > 5Vwy6wf+LT48qoMsNTPL/P+l0m+TmgpWHDffyDsBrImnQUQh0v4L6jkZUYt2bMjd > > bYeRnsG8TEg+Gsv5fwgQf/m2sVpO6yNou+7GTkoZxFC7BNRh43al+ErXXGL+qTJX > > cqG/yFgoYVlAY9BJKvKNdBT0l9SuBAZu8XwiAMGV6VaRjcgNgSXwy2VPULBDF42L > > AN4lh3/Vh0uRWKFZDcTMOdIBFhIbgKWBhkp5DzDtT8+kCp6uTvD8jyd4+q6Mp7tZ > > mCiIgJ5UMUR7wXFcevOuVi8Zm90Bd3FoRHftr8uccDryVykHpd8aNR5lD53vkFGA > > X/slznIMMn4qPShubXISIxv+5O2gEA== > > =7ett > > -----END PGP SIGNATURE----- > > -------------- 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 ripe-wgs at radu-adrian.feurdean.net Wed Mar 13 17:07:59 2019 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Wed, 13 Mar 2019 12:07:59 -0400 Subject: [address-policy-wg] PA ??? life after death In-Reply-To: References: <2019084.3GHfbMEebd@hunator-ntb.local> Message-ID: <85358f7a-2b2f-407e-98a0-ea584962f7e4@www.fastmail.com> On Tue, Mar 12, 2019, at 18:48, Maxim A Piskunov wrote: > Please explain anybody, "PI in IPv4 is not coming back" -- is any rules > what prohibit community to turn situation to allow PA to PI conversion > for use by end-user purposes? Yes: The rule that says that needs to be a proposal for the policy to change (in order to allow that), and the proposal is accepted by the community following the PDP (which is the point where things start getting VERY complicated - such a proposal will most likely be rejected). -- Radu-Adrian FEURDEAN From jordi.palet at consulintel.es Sat Mar 16 11:45:28 2019 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 16 Mar 2019 11:45:28 +0100 Subject: [address-policy-wg] 2019-01 Review Phase (Clarification of Definition for "ASSIGNED PA") Message-ID: <2B882F08-A3D6-468F-A52C-392076D16767@consulintel.es> Sorry, ?I've not participated in the discussion, but just read all the thread and the impact analysis, and I'm supporting as well. Regards, Jordi ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com 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 Sat Mar 16 11:58:20 2019 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 16 Mar 2019 11:58:20 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) Message-ID: Same here, sorry, ?I've not participated in the discussion, a bit overloaded with daily work, but just read all the thread, and I'm supporting it. Further I can add some data. I've participated in APNIC 47, and prop-127, which is mention in this proposal, reached consensus. I've also discussed the same topic in the LACNIC mailing list, and I'm considering a similar proposal there. To be clear, I'm talking about the same as APNIC prop-127, which is moving the maximum allocation from /22 to /23. Regards, Jordi ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com 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 Mar 21 12:36:58 2019 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 21 Mar 2019 12:36:58 +0100 Subject: [address-policy-wg] RIPE 77 Address Policy WG Draft Minutes Message-ID: Dear colleagues, The draft minutes from the Address Policy Working Group sessions at RIPE 77 have now been published: https://www.ripe.net/participate/ripe/wg/ap/minutes/ripe-77-address-policy-working-group-minutes Please let us know of any corrections or amendments. Kind regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From ripedenis at yahoo.co.uk Fri Mar 22 10:59:44 2019 From: ripedenis at yahoo.co.uk (ripedenis at yahoo.co.uk) Date: Fri, 22 Mar 2019 09:59:44 +0000 (UTC) Subject: [address-policy-wg] Clarification of policy requirements for contact information References: <268675215.15226408.1553248784300.ref@mail.yahoo.com> Message-ID: <268675215.15226408.1553248784300@mail.yahoo.com> Colleagues, Elvis, James and myself have started talking about personal data in the RIPE Database. I said we would bring sub issues to the community when we need direction or clarification. We looked at three policy documents maintained by AP-WG and have a few questions. Before we look at WHERE and HOW the data is stored, we would like to get community feedback on exactly WHAT contact details should be published as per current policies? Below are the quotes and links to the 3 policy documents we looked at. cheersdenisco-chair DB-WG In the "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" (ripe-708) [1] first mention about contact data is 4.0: "4.0 Registration Requirements All assignments and allocations must be registered in the RIPE Database. This is necessary to ensure uniqueness and to support network operations.? Only allocations and assignments registered in the RIPE Database are considered valid. Registration of objects in the database is the final step in making an allocation or assignment. Registration data (range, contact information, status etc.) must be correct at all times (i.e. they have to be maintained)." and then in 6.2: "6.2 Network Infrastructure and End User Networks IP addresses used solely for the connection of an End User to a service provider (e.g. point-to-point links) are considered part of the service provider's infrastructure. These addresses do not have to be registered with the End User's contact details but can be registered as part of the service provider's internal infrastructure. When an End User has a network using public address space this must be registered separately with the contact details of the End User. Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End Users. [...]" In the "IPv6 Address Allocation and Assignment Policy" (ripe-707) [2] the requirement is even more vague in 3.3: "3.3. Registration Internet address space must be registered in a registry database accessible to appropriate members of the Internet community. This is necessary to ensure the uniqueness of each Internet address and to provide reference information for Internet troubleshooting at all levels, ranging from all RIRs and IRs to End Users. The goal of registration should be applied within the context of reasonable privacy considerations and applicable laws." The "Autonomous System (AS) Number Assignment Policies" [3] does not mention anything about contact data requirements. [1] https://www.ripe.net/publications/docs/ripe-708[2] https://www.ripe.net/publications/docs/ripe-707[3] https://www.ripe.net/publications/docs/ripe-679 -------------- next part -------------- An HTML attachment was scrubbed... URL: