[address-policy-wg] PA ??? life after death

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 <hunekm at 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.
>
> 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 at 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-----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20190312/222bff58/attachment.html>