[address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)

Hi Carlos,

sorry for the late reply I was out for work.

I'll reply only to your question "> Fix IPv6 rate adoption by policy? "
Carlos, this policy proposal aims to fix IPv4 rate depletion... so why 
don't use a policy for "rate adoption"? do you see any difference?
Rest is personal opinion and from my point of view any conservative 
policy will only last the pain longer.

thank you
regards
Riccardo



Il 24/09/2017 15:09, Carlos Friaças ha scritto:
>
> Hi Riccardo, All,
>
> Thanks for your input.
>
> Please see inline.
>
>
> On Sun, 24 Sep 2017, Riccardo Gori wrote:
>
>> Dear all,
>>
>> I started as an ISP early 2015 and I still consider myself a new 
>> entrant.
>
> That's not my definition for "new entrant". Strictly i consider a new 
> entrant as an organization which doesn't own any IPv4 or IPv6 address 
> space. Loosely, it can be a new LIR (before getting its /22 and an 
> IPv6 block under current policy)...
>
> But, luckly the community approved a policy for the last /8 long 
> before 2015. If that didn't happen, your only solution would have been 
> to rely on the market.
>
>
>> In the last 2 years I heard about a couple of time "no more IPv4 
>> policies let's go over and think how to fix/help IPv6 rate adoption" 
>> but today we are still here complaining what's the best way to last 
>> longer with the agony.
>
> Is "no more IPv4 policies" written in stone somewhere? :-)
>
> Fix IPv6 rate adoption by policy?
> Let's call our countries' telecom regulators, and ask for a policy 
> that prohibits IPv4 usage from day X onwards? -- i don't think 
> so...........
>
>
>> For Ipv6 RIPE NCC is doing its best with training and is really 
>> appreciated
>
> +1 on that!
>
>
>> and I learned here that we tend to not mix IPv4/6 policies but I 
>> really expected incentives from the cummunity not obstacles. The 
>> "IPv6 Requirement for Receiving Space from the Final /8" was 
>> abandoned 23/10/2014 by the adoption of 2014-04 proposal
>
> Looking back now, was that a good decision...?
>
>
>> while this 2017-03 proposal aims to last as longer as possible with 
>> IPv4.
>
> Should we tweak it, and make it more "stricter", in a way the address 
> space is (automatically?) returned if it's not being used in v4/v6 
> translation mechanisms...? (and do we have means to check that?)
>
>
>
>> Looks to me that we are trying to save future generation from ice 
>> melting saving oil tanks instead of working on research and 
>> incentives to clean energies.
>
> Incentives cost money -- taxpayers' or consumers' money (or both!)
>
>
>> I don't see even any reason to save more address space than the 
>> current policies does 'casue we have "trasfert policies"
>
> Transfers of last /8 slices are still allowed after 24 months -- 
> should that possibility end...? (2017-03 v1.0 doesn't address transfers)
>
>
>> for almost any kind of IP resource and if there are some restrictions 
>> on new allocation there are more flexible for legacy space.
>
> The RIPE community (through the NCC) only provides services to legacy 
> space holders (and there was a proprosal for that... 2012-07).
> The RIPE community is not able to design policies regarding address 
> space which was distributed before the NCC's creation.
>
>
>
>> Today you can simply choose to go RIPE or market as your feeling to 
>> get IPv4/6 if needed.
>
> If the choice is going to the "market" (and if you are in strict sense 
> a new entrant), the "market" will not advocate you should use/deploy 
> IPv6.
> On the other hand, if the choice is becoming a LIR, you will get 
> that... :-)
>
>
>
>> My small router deals today with more than 2.5 million routes (2 full 
>> routing tables and some IX) and it really takes time to backup and 
>> even routing performance are affected by volume of routes. I think we 
>> should propote IPv6 for route aggregation ability.
>
> There is also de-aggregation in IPv6-land. :-(
> (http://www.cidr-report.org/v6/as2.0/)
> People will mess up routing as the rest of the world lets them...
>
>
>> I see this policy as:
>> - an obstacle to IPv6
>
> That was not the goal. The goal was to extend v4 availability for some 
> more time, thus making life easier for IPv6 deployments that will 
> still need to talk with the v4 world.
>
>
>> - a clear side effect of market price rise on IPv4
>
> This proposal is not about the "market". a /24 can cost X, Y or Z over 
> time. The only way we can keep "affordability" for new entrants is by 
> defining what they get from the NCC, not from any 3rd party.
>
>
>
>> - a disincentive to route aggregation
>
> I don't agree. /22s (and bigger chunks) are already being announced as 
> /24s. What we consider is that keeping the "affordability" for new 
> entrants is a bigger priority than keeping the DFZ on 683k (today) 
> instead of 725k, 750k or even 800k routes. I know 800k routes looks 
> insane, but two years ago 683k would have been equally insane :-))
>
> ps: On 24-09-2015 (two years ago), 572876 routes
> https://web.archive.org/web/20150924225101/https://www.cidr-report.org/as2.0/ 
>
>
>
> Thanks!
>
>
> Best Regards,
> Carlos Friaças
>
>
>> That's why I oppose this policy
>> kind regards
>> Riccardo
>>
>> -- 
>> Riccardo Gori
>>

-- 

Ing. Riccardo Gori
e-mail: rgori at wirem.net
Italia:  +39 339 89 25 947
España:  +34 660 11 59 89
Profile: https://it.linkedin.com/in/riccardo-gori-74201943

WIREM Fiber Revolution
Net-IT s.r.l.
Via Cesare Montanari, 2
47521 Cesena (FC)
Tel +39 0547 1955485
Fax +39 0547 1950285

--------------------------------------------------------------------
	CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please contact us by re-
plying to info at wirem.net
         Thank you
WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC)
--------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20171007/fd91878b/attachment.html>