<div dir="ltr"><div dir="ltr">Hello, Marting, Members.<div> </div><div>>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. </div><div> </div><div>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?</div><div>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.</div></div></div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 8 Mar 2019 at 15:19, Martin Huněk <<a href="mailto:hunekm@gmail.com">hunekm@gmail.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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 <<a href="mailto:wusel%2Bml@uu.org" target="_blank">wusel+ml@uu.org</a>> 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----- </blockquote></div>