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 <[email protected]> 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 <[email protected]> > 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----- >
