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?
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?
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?
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/ <http://www.gcxc.net/> 140180, Zhukovskiy, Lomonosova 29a
6 марта 2019 г., в 20:24, Max Tulyev <president@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?
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
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 <stary.bezpiecznik@gmail.com> написал(а):
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
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
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 <sander@steffann.nl> написал(а):
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
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 <it@gcxc.net> 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 <sander@steffann.nl> написал(а):
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
- 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
Hello, Sander! 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 <sander@steffann.nl> 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
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
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
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 <gert@space.net> 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
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
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 <wusel+ml@uu.org> 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
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
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 <wusel+ml@uu.org> 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 > > > >
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<tel:08750969>. Registered office: 88 Wood Street, London, United Kingdom, EC2V 7RS. On 7 Mar 2019, at 06:00, Maxim A Piskunov <ffamax@gmail.com<mailto:ffamax@gmail.com>> 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 <wusel+ml@uu.org<mailto:wusel%2Bml@uu.org>> 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
Nice joke. 07.03.19 08:55, Dominik Nowacki пише:
IPv4 is dead. Focus on deploying IPv6 where you can get a PI allocation.
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 <wusel+ml@uu.org> 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
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
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.
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 <hunekm@gmail.com> 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
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
Dne pátek 8. března 2019 14:02:34 CET, Stary Bezpiek napsal(a): 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-----
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<tel:08750969>. Registered office: 88 Wood Street, London, United Kingdom, EC2V 7RS. On 8 Mar 2019, at 13:02, Stary Bezpiek <stary.bezpiecznik@gmail.com<mailto:stary.bezpiecznik@gmail.com>> 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
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 <address-policy-wg-bounces@ripe.net> en nombre de Dominik Nowacki <dominik@clouvider.co.uk> Fecha: viernes, 8 de marzo de 2019, 14:45 Para: Stary Bezpiek <stary.bezpiecznik@gmail.com> CC: "address-policy-wg@ripe.net" <address-policy-wg@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 <stary.bezpiecznik@gmail.com> 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.
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
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
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".
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
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.
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.
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
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
in APWG. Also allowing transfer of resources which is being closed for
Hello, Marting, Members. pass 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 <hunekm@gmail.com> 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.
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
Dne čtvrtek 7. března 2019 6:59:52 CET, Maxim A Piskunov napsal(a): 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 <wusel+ml@uu.org> 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-----
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 <hunekm@gmail.com> 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.
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
Dne čtvrtek 7. března 2019 6:59:52 CET, Maxim A Piskunov napsal(a): 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 <wusel+ml@uu.org> 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-----
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
participants (15)
-
Carlos Friaças -
Dominik Nowacki -
Gert Doering -
JORDI PALET MARTINEZ -
Kai 'wusel' Siering -
Martin Huněk -
Max Tulyev -
Maxim A Piskunov -
Maximilian Wilhelm -
Nikolay Gorstkin -
Radu-Adrian FEURDEAN -
Sander Steffann -
Sergey Myasoedov -
Stary Bezpiek -
Vitaliy joness