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

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 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 --------------
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: </ripe/mail/archives/address-policy-wg/attachments/20190313/843f2a12/attachment.sig>