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

> P.S : This time I use my v6 smtp server even though at home I cannot
> still use a v6 prefix ;)

interesting to see the whole trail.

Received: from psg.com ([2001:418:1::62])
by ran.psg.com with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.86_2)
(envelope-from )
id 1dvx51-000885-77
for ra...@ran.psg.com; Sun, 24 Sep 2017 02:55:39 +
Received: from [2001:67c:2e8:11::c100:1372] (helo=mahimahi.ripe.net)
by psg.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256)
(Exim 4.89 (FreeBSD))
(envelope-from )
id 1dvx50-000K7L-8w
for ra...@psg.com; Sun, 24 Sep 2017 02:55:38 +
Received: from titi.ripe.net ([193.0.23.11])
by mahimahi.ripe.net with esmtps 
(TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256)
(Exim 4.89)
(envelope-from )
id 1dvx4r-000Am2-6a; Sun, 24 Sep 2017 04:55:31 +0200
Received: from chouchou.ripe.net ([193.0.19.37])
by titi.ripe.net with esmtps 
(TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256)
(Exim 4.89)
(envelope-from )
id 1dvx4q-0008Iz-TD; Sun, 24 Sep 2017 04:55:28 +0200
Received: from localhost.localdomain ([127.0.0.1] helo=chouchou.ripe.net)
by chouchou.ripe.net with esmtp (Exim 4.84_2)
(envelope-from )
id 1dvx4q-0002yO-O6; Sun, 24 Sep 2017 04:55:28 +0200
Received: from mahimahi.ripe.net ([2001:67c:2e8:11::c100:1372])
 by chouchou.ripe.net with esmtp (Exim 4.84_2)
 (envelope-from ) id 1dvx4p-0002yI-Oa
 for address-policy...@lists.ripe.net; Sun, 24 Sep 2017 04:55:27 +0200
Received: from ran.psg.com ([2001:418:8006::18])
 by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128)
 (Exim 4.89) (envelope-from ) id 1dvx4o-000Alk-Lk
 for address-policy-wg@ripe.net; Sun, 24 Sep 2017 04:55:27 +0200
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net)
 by ran.psg.com with esmtp (Exim 4.86_2)
 (envelope-from )
 id 1dvx4l-00087z-Nh; Sun, 24 Sep 2017 02:55:24 +

as i said, thanks to NTT i have no ipv6 at home.  but it goes v6 as soon
as it hits my outbound smtp server, arrives at the ncc over ipv6,
bounces around within the ncc over ipv4, and then exits the ncc over
ipv6

randy

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

[ generally good analysis ]

> The only use case RIPE NCC should assign new IPv4 address space for is
> for documented and needed v6 transitions services

do not make rules you can not measure or enforce.  it weakens the
credibility of the rest of the structure.

randy

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

> In both scenarios relying on only IPv4 is insanity,

it's a business decision, and probably has many factors behind it.  you
and i might think it unwise, but 'insanity' is a bit in the weeds.

> They are beyond help

not at all.  the vendors are more than happy to sell them CGNs, and
other NATs of many flavors.  i just don't like the result.

but, as i said, we have demonstrated time and again that we can not
seriously affect the tragically slow deployment of ipv6.  so i do not
make decisions based on changing that.

>> P.S : This time I use my v6 smtp server even though at home I cannot
>> still use a v6 prefix ;)

same here, darn it.  welcome to NTT B-Flets land.

randy

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

2017-09-23 Thread Kai 'wusel' Siering

Hi,

am 23.09.2017 um 23:51 schrieb Willy MANGA:
> Hi Nick,
>
> Le 23/09/2017 à 21:41, Nick Hilliard a écrit :
>> Willy MANGA wrote:
>>> being a newbie here can you please explain briefly why, as of today ,
>>> these people really need IPv4 addresses ?
>> I'd be tempted to answer, except that you sent this email from an ipv4
>> address.  So, please deconfigure all IPv4 addresses from your computer,
>> re-send the email, and then I'll answer.
> From where I stand (at home in Cameroon, Central Africa), My ISP has /32
> on v6 since 2013 but nothing deployed. Why ? I suspect ignorance and no
> incentive.
> I use to poke some friends working in telco fields; they say they are
> some work in the background :)
>
> From where I work, I did my best to deploy IPv6 in our networks [1] [2]
> Our ISP here has its v6 prefix since ... 11 years.  We are its first
> customer requesting v6 and they deploy it for us.
>
> I keep pushing in my area but as you may guess, it's the most difficult
> one but I succeed at least in my organisation.
>
> So again, why do they rely on v4 (only) ? I really want to understand
> hurdles on european continent.
>
> I hope this time, it will be clearer :)

Oh, the question was clear already; the answer was a bit of a puzzle.

There are two Internets these days, the really old, 32 bit one, and the other 
one, based on 128 bit addressing.

Different infrastructures, that can run alongside each other over the same 
cable, but don't know of the other.

As you've noticed yourself already, IPv6 adoption is slow. So there's less 
incentive to run services on IPv6, which increases the need for IPv4 addresses.

It's not too difficult to predict that IPv4-only services and servers will be 
around for the next decades.

As you already have IPv4 and IPv6 address space, you can run Dual Stack, e. g. 
have v4 (maybe NATed) and v6 on each client, so each of your client systems can 
reach v4 and v6 destinations.

If you don't have any publicly routed v4 address, you're be restricted to the 
upcoming, nice-and-shiny, IPv6-based, end-to-end Internet. Which, 
unfortunately, is only a subset of what is available in the rusty, IPv4-based, 
initial version.

I recently tried it myself, setting up a VM for an audience that "usually" is 
v6-enabled, so I thought "cut the crap, we do this one v6-only". So the VM only 
received v6 networking. And then I tried to update it to the current patchlevel 
— and I noticed that v4 is still a necessity:

root@discourse:~# host de.archive.ubuntu.com
de.archive.ubuntu.com is an alias for ubuntu.mirror.tudos.de.
ubuntu.mirror.tudos.de has address 141.76.1.208
ubuntu.mirror.tudos.de has address 141.30.62.22
ubuntu.mirror.tudos.de has address 141.76.1.204
ubuntu.mirror.tudos.de has address 141.30.62.23
ubuntu.mirror.tudos.de has address 141.76.1.200
root@discourse:~#

No v6 address, so no updates. (Sure, I could have used uk.archive.ubuntu.com, 
which is available on v6 as well, but you will not always find a replacement 
URL that works on v6-only.) So that VM now does have an RFC1918 IPv4 address 
that's NATed on the Hypervisor ...

To make a long story short: if you want to start a new internet service, you 
need connectivity to the legacy, IPv4-based, Internet. There are v4-only 
customers out there (e. g. business customers of Unitymedia (Liberty Global's 
German branch) only get one public v4 IP for NAT and cannot get v6 at all), and 
this is not going to change anytime soon, as you can see in your area as well. 
Actually, even some public clouds didn't provide v6 until recently. And, in 
some cases, at least for parts of their fleet confirmed they never will.

The question at hand is: how long should the RIPE Community keep the door open? 
IPv4 is already restricted to new LIRs, and LIRs are supposed to hand that 
space down to their customers. If your business needs new IPv4 space, these 
days you have to become a new LIR, which as of now costs you a 2000 EUR signup 
fee and a 1400 EUR yearly fee. Currently you'll get a /22, i. e. 4 /24, with no 
questions asked (and an /29 of v6, IIRC). And a(nother) vote in the RIPE NCC 
assembly ...

2017-03 would change this to "you get a /24" per new LIR, effectively raising 
the cost of an /24 from ~85 EUR/month to ~173 EUR/month (assuming 36 months to 
"earn back" the signup fee), but not enforcing IPv6 deployment in any way.

If we, as the RIPE Community, really want to preserve the scarse IPv4 
ressources for "new entrants" to be able to deploy v6, more is needed than just 
shrinking the assignment: IPv4 *is* done.
The only use case RIPE NCC should assign new IPv4 address space for is for 
documented and needed v6 transitions services — and it has to prohibit 
transfers on this space, as any transfer would nullify the initial use case 
anyway, therefore opening the path to reclaim the assignment. And to make this 
setup last even longer, only a /28 should be assigned, as you don't need 256 
IPs for a 6-to-4-gateway service anyway

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

2017-09-23 Thread Sander Steffann

Hi,

> So again, why do they rely on v4 (only) ? I really want to understand
> hurdles on european continent.

I think the hurdles are roughly the same in all regions. Relying on only IPv4 
is insanity, and those that do so deserve no sympathy. But as you have 
personally experienced IPv6 isn't available everywhere and for everything yet. 
Therefore everybody still needs some IPv4 to communicate with those laggards. 

This community has so far considered it its responsibility (statement based on 
current policy) to make sure new entrants can do so without having to rely on 
getting IPv4 addresses through/from third parties. For almost all participants 
on the internet having at least some IPv4 space is vital for at least the next 
decade. 

What they get is a tiny amount of IPv4 space from RIPE NCC when they sign up as 
LIR. So far that tiny amount has been a /22. Now that the end of those /22s is 
in sight this community has to choose. Either keep the current policy and let 
it run out completely and let newcomers fend for themselves (if possible, 
32-bit space is finite and at some point the market will dry up and IPv4 space 
will become unavailable/unaffordable) or change the /22 to /24 and keep giving 
newcomers a tiny bit of addresses for a while longer (what is currently being 
proposed).

This community doesn't face an easy choice: keeping some IPv4 addresses 
available for newcomers can send the wrong message, that IPv4 hasn't "really" 
run out. Letting RIPE NCC run out completely will definitely fix that. On the 
other hand that will also send the message that the current internet 
participants want to keep newcomers out, or at last dependent on the 
willingness of current participant to part with some of their address space. 
That can be seen as anti-competitive and unfair. I really understand both sides 
of that argument (as I should, being a chair!).

In both scenarios relying on only IPv4 is insanity, and I have a strong feeling 
that this community does not have the slightest bit of sympathy for those 
planning to do so. They are beyond help, so let them spend their own money on a 
failing technology. Any sympathy is for those who come to the party late but 
still have to deal with the laggards (and idiots) already present.

> Assuming those who request v4 addresses have a transition plan (what I deeply 
> hope ... )

One would indeed hope so.

> P.S : This time I use my v6 smtp server even though at home I cannot still 
> use a v6 prefix ;)

:)

Cheers!
Sander

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

2017-09-23 Thread Nick Hilliard

Willy MANGA wrote:
> So again, why do they rely on v4 (only) ? I really want to understand
> hurdles on european continent.
> 
> I hope this time, it will be clearer :)

same reason as in africa: for most organisations it's too much work with
too little return.

Many humans will only react after a crisis hits, even if the cost of
that is higher overall.

Nick

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

2017-09-23 Thread Willy MANGA

Hi Nick,

Le 23/09/2017 à 21:41, Nick Hilliard a écrit :
> Willy MANGA wrote:
>> being a newbie here can you please explain briefly why, as of today ,
>> these people really need IPv4 addresses ?
> 
> I'd be tempted to answer, except that you sent this email from an ipv4
> address.  So, please deconfigure all IPv4 addresses from your computer,
> re-send the email, and then I'll answer.

>From where I stand (at home in Cameroon, Central Africa), My ISP has /32
on v6 since 2013 but nothing deployed. Why ? I suspect ignorance and no
incentive.
I use to poke some friends working in telco fields; they say they are
some work in the background :)

>From where I work, I did my best to deploy IPv6 in our networks [1] [2]
Our ISP here has its v6 prefix since ... 11 years.  We are its first
customer requesting v6 and they deploy it for us.

I keep pushing in my area but as you may guess, it's the most difficult
one but I succeed at least in my organisation.

So again, why do they rely on v4 (only) ? I really want to understand
hurdles on european continent.

I hope this time, it will be clearer :)


1. https://nda.manbene.net/index.php/s/JJPCt8OVzoxNXCv (english)

2. https://nda.manbene.net/index.php/s/j5himX7Bfjk7OaV (french)

>> Or at least why they cannot
>> start a transition process towards IPv6?
> 
> Without ipv4 addresses, transition technologies don't work.

Assuming those who request v4 addresses have a transition plan (what I
deeply hope ... )


P.S : This time I use my v6 smtp server even though at home I cannot
still use a v6 prefix ;)

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

2017-09-23 Thread Nick Hilliard

Willy MANGA wrote:
> being a newbie here can you please explain briefly why, as of today ,
> these people really need IPv4 addresses ?

I'd be tempted to answer, except that you sent this email from an ipv4
address.  So, please deconfigure all IPv4 addresses from your computer,
re-send the email, and then I'll answer.

> Or at least why they cannot
> start a transition process towards IPv6?

Without ipv4 addresses, transition technologies don't work.

Nick

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

2017-09-23 Thread Willy MANGA

Hi,

Le 22/09/2017 à 08:47, address-policy-wg-requ...@ripe.net a écrit :
> [...]
> I'm working around IPv6 since 2001. Anna and Randy probably since before 
> that. We have deployed IPv6. It didn't enable us to completely get rid of 
> IPv4 within our networks. That also didn't solve any issue for 3rd party 
> networks -- they all still need IPv4 addresses.

being a newbie here can you please explain briefly why, as of today ,
these people really need IPv4 addresses ? Or at least why they cannot
start a transition process towards IPv6?


Regards,

-- 
Willy Manga
@ongolaboy
https://ongola.blogspot.com/





signature.asc
Description: OpenPGP digital signature

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

>> When do we distribute 240/4 among the RIRs as "really last /8s"?
> 
> I made that question myself during an ICANN meeting (the only i
> attended) 10 years ago. The answer was something about operating
> systems' stacks. I wasn't fully convinced, but a large majority of
> internet plumbers seems to buy it...

analogous to one's need for ipv4 reachability until the last ipv4 sites
die out, if any equipment does not properly route and forward 240/4 then
there will be folk who can not reach those with addresses drawn from
that space.

darned shame but we do need universal reachability.

we do not have a good track record for addressing architectures.  check
out rfc 2450 when you have not eaten recently.

randy

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

2017-09-23 Thread Carlos Friaças




Hi,


On Sat, 23 Sep 2017, Kai 'wusel' Siering wrote:

(...)

Where does this 'responsibily' end?


Don't know, but still feel we should try for the coming years.



When will be "well, the IPv4 well dried out back in 2011;


It didn't completely (even today), but the RIPE NCC service region entered 
"scarcity-mode" in Sept'2012.



it's now just done, you're simply too late" a 'responsible' answer? If 
not 2020/2021 (as based on current prediction), how about 2022? 2030? 
2080?


If two years of more v6 deployment help, there is some benefit. If it's 10 
more years, great. v6 deployment is slow -- that we know.




When do we distribute 240/4 among the RIRs as "really last /8s"?


I made that question myself during an ICANN meeting (the only i attended) 
10 years ago. The answer was something about operating systems' stacks. I 
wasn't fully convinced, but a large majority of internet plumbers seems to 
buy it...




Seriously, this is ridiculous. IPv4 is done.


For expanding the Internet, sure. There is however, a tiny annoying bit: 
IPv4 is still the dominant Internet Protocol version in terms of usage :/




"get over it.  get a life." And deploy IPv6.


Been there, done that.
Sometimes i see some of it going back to IPv4-only, though :(

And the biggest issue, we can't really force 3rd parties do deploy it. If 
some of those 3rd parties don't need to grow their infrastructures, the 
"incentive" to deploy IPv6 is really small :/




Actually a common tune[1] a decade before today already ;)


I actually was in the room when that happenned! :-))
On 26th Oct'2007 [1][2].

[1] https://www.ripe.net/participate/meetings/ripe-meetings/ripe-55
[2] 
https://www.ripe.net/participate/meetings/ripe-meetings/ripe-55/attendee-list


Thanks for your input.


Cheers,
Carlos




Regards,
-kai

[1] https://www.youtube.com/watch?v=_y36fG2Oba0

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

>> as a friend wrote privately
>> I would be interested to have a person who is 16 years old reply:
>> "I am planning to open my own internet company in 4 years; can you
>> please save some address space for me, 'til I finish high school?"
>> But of course, there is no such person on the RIPE mailing list..
>> and we are responsible to those 14 year olds.
> If he has the money to become a RIPE LIR right out of school

he?  wrong.

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

2017-09-22 Thread Kai 'wusel' Siering

Am 23.09.2017 um 02:24 schrieb Randy Bush:
> the point here is simple.  the ripe community has a responsibility to
> the human community beyond the members of this list.

But the RIPE Community cannot change the laws of physics or, for that matter, 
math.

2³² just wasn't enough numbers, deal with it.

> as a friend wrote privately
>
> I would be interested to have a person who is 16 years old reply:
>
> "I am planning to open my own internet company in 4 years; can you
> please save some address space for me, 'til I finish high school?"
>
> But of course, there is no such person on the RIPE mailing list..
>
> and we are responsible to those 14 year olds.

If he has the money to become a RIPE LIR right out of school, he *might* still 
get a /22 by then.

Note, though, "internet company" does not necessarily involve IPv4. Nor does it 
mean that he has to become an LIR; actually, many LIRs will be around that can 
supply him with v4 PA space and connectivity, e. g. those LIRs that existed 
before A6 and ip6.int got deprecated ...

Now, the children of my offsprings, which might have still a decade or so to 
conception, what's with them? How do you intend to steward v4 usage to ensure 
them the same chances to "open their own internet company" in, say, 28 years? 
Or, more likely, their potential parents in, say, 8 years from now, after them 
finishing School and University?

Where does this 'responsibily' end? When will be "well, the IPv4 well dried out 
back in 2011; it's now just done, you're simply too late" a 'responsible' 
answer? If not 2020/2021 (as based on current prediction), how about 2022? 
2030? 2080? When do we distribute 240/4 among the RIRs as "really last /8s"?

Seriously, this is ridiculous. IPv4 is done. "get over it.  get a life." And 
deploy IPv6. Actually a common tune[1] a decade before today already ;)

Regards,
-kai

[1] https://www.youtube.com/watch?v=_y36fG2Oba0

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

> I don't think that there is anyone whom would not be able to justify
> /22.

i think there are a vast number of entities which could justify a /16.
so?  there is this little problem. 2^32 is bounded.

randy

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

it might be wise to avoid the eternal rat-hole of what will and will not
increase ipv6 deployment.  whether we like it or not, and whether we
excoriate the folk who have not deployed or not, history has shown that
we do not know.

there are no more 32-bit integers.  ipv6 is horrifyingly and tragically
slow to deploy.  get over it.  get a life.

those of us who have been around a while have heard it all before.
raise your hand if you remember when 3gpp was going for force global
ipv6 deployment.  shall i start down the list of the other things?

[ remember my $dayjob deployed in 1997 and my co-worker wrote the kame
stack on which many of your ipv6 implementations are based. ]

the point here is simple.  the ripe community has a responsibility to
the human community beyond the members of this list.  as a friend wrote
privately

I would be interested to have a person who is 16 years old reply:

"I am planning to open my own internet company in 4 years; can you
please save some address space for me, 'til I finish high school?"

But of course, there is no such person on the RIPE mailing list..

and we are responsible to those 14 year olds.

it is called stewardship.

randy

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

>> do we know how many LIRs eligible under the current policy have not
>> yet asked for a final /22?
> So, 13950 /22s between Q4/2012 and today, hence i would say your
> answer is around 2404 LIRs (16354-13950).

i tend to agree with the suggestion that folk with ipv4 space already
are not eligible

randy

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

2017-09-22 Thread Kai 'wusel' Siering

Hi,

am 22.09.2017 um 16:50 schrieb Anna Wilson:
> Hi Tom,
>
>> On 22 Sep 2017, at 15:37, Tom Hill > > wrote:
>>
>> Because I don't see a way in which this policy will change anyone's
>> behaviour, or incentivise them differently over the current policy, I
>> don't believe it needs to be changed. If you would like, we can take
>> IPv6 adoption out of the argument completely, and I can still be solely
>> against it for the reason of changing the status quo on acceptable
>> prefix sizes for no perceivable gain to anyone.
>
> The proposal doesn't have a goal of changing anyone's behaviour or 
> incentivising anyone. The goal is to quadruple the number of remaining IPv4 
> applications that RIPE NCC can fulfil.
>
> So the gain is to those three quarters of applications that would otherwise 
> be unsuccessful.

As pointed out by others already, the change from /22 to /24 just quadruples 
the per-IP price tag. Due to the cost involved, 2017-03 may shortly reduce the 
amount of IPv4 space assigned to "new entrants". From my perspective, this 
effect will be short lived, as simply more "PI-LIRs" will be created to get 
IPv4 space before it's gone (and/or getting even more expensive).

> I'd gently suggest the counter:
>
> - that new entrants are most likely to support IPv6 (because very little IPv4 
> can be got);

If you finally hold your expensive v4 space, best to make it work for the 
money. But each new dual-stacked or, worse, v4-only service and user lessens 
the pressure on anyone to switch to v6.

> - that even fully IPv6-ed new entrants need some IPv4 to make IPv6 work;

I've read this point multiple times in this thread; but which part of IPv6 
needs public IPv4 addresses to make IPv6 work? These are completely independent 
protocols (which is part of the problem and part of the solution ;)), used to 
create independent networks.

> - reaching IPv4 runout while this is still the case will hurt those new 
> entrants disproportionately;

Isn't this the way of live? IPv4 is considered legacy, and the RIRs do a 
tremendous job at prolonging it's life span with their last /8 policies.

But IPv4 has no future, it's address space is effectively gone (except for 
240/4 …). How long shall we prolong IPv4's infirmity? At current rate (and 
policies), RIPE NCC will run out of IPv4 addresses to allocate somewhere around 
2020 or 2021? This was meant to happen some time, and it will happen some time, 
regardless of the policy in place.

Another issue I see with the proposed policy: With 2017-03 in place, new 
LIRs[1] would be severly restricted in their business options, compared to 
ripe-680. I see no change in the situation since the last /8 policy went into 
effect that would justify this. Everything runs as expected.

I'd support a change of 5.2, though: instead of serving the last 64 LIRs with a 
/22, use that /16 for 256 /24 allocations (or less, depending on routability at 
that point) along ARINs current policy[2].

Regards,
-kai

[1] 
https://www.ripe.net/manage-ips-and-asns/resource-management/faq/independent-resources/def-terms
[2] https://www.arin.net/policy/nrpm.html#four10

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

2017-09-22 Thread Peer Kohlstetter

Hello WG,

the discussion shows that there are a lot of pros and cons about this proposal. 

But the strongest argument for me is that we will have IPv4 around for very 
long time and this proposal help to gives every newcomer a fair start. That's 
the main Idea of the last /8. 

Because of this I support the proposal. 

The IPv4 world with BGP, NAT, CGN and IPv4 Transfers has shown big 
adaptability. If the best argument for IPv6 rollout is the end of the IPv4 
world, we have to wait very long for a widely used IPv6 Internet. IPv4 is a 
very robust beast. Because of this we use and love it. :-)

Best regards,

Peer


blue networks GmbH & Co KG
Peer Kohlstetter
Mail: kohlstet...@blue-networks.de

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

2017-09-22 Thread Kaveh Ranjbar

> On 22 Sep 2017, at 13:24, David Farmer  wrote:
> 
> On Fri, Sep 22, 2017 at 5:04 AM, Tim Chown  wrote:
> ... and ARIN are on a last /10 policy which sees applicants get a /28 to a 
> /24, so presumably those /28’s are routed at some level; that’s been in place 
> for some time, how is it working out? ...
>  
> This ARIN policy is in section 4.10 of ARIN's NRPM;
> 
> https://www.arin.net/policy/nrpm.html#four10 

Hello WG,

To shed some more light on routability of prefixes longer than /24, we started 
an experiment when the aforementioned policy change was being discussed at 
ARIN. From October 2014, we started announcing 6 prefixes from ARIN’s  
designated block 23.128/10. There are /24, /25 and /28 prefixes, with and 
without IRR objects.

We then measured visibility and reachability of those prefixes both on the 
control plane (by looking at BGP) and on the data plane (using RIPE Atlas trace 
routes).

You can find the original paper by Emile Aben at 
https://labs.ripe.net/Members/emileaben/propagation-of-longer-than-24-ipv4-prefixes
 as well as a followup in 2015 
https://labs.ripe.net/Members/emileaben/has-the-routability-of-longer-than-24-prefixes-changed
 and finally, a more recent followup by Stephen Strowes on 10th of July 2017: 
https://labs.ripe.net/Members/stephen_strowes/bgp-even-more-specifics-in-2017

All the best,
Kaveh.

———
Kaveh Ranjbar,
Chief Information Officer,
RIPE NCC.

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

2017-09-22 Thread Peter Koch

Anna, all,

On Fri, Sep 22, 2017 at 01:56:13PM +0100, Anna Wilson wrote:

> It's not an unreasonable effect to hope for. But the current /8 policy is 
> already quite restrictive. I would be surprised if full runout would have a 
> much greater effect on existing IPv4 holders. And even if that effect is 
> something above negligible, the burden of it falls disproportionately on 
> post-runout new entrants.

do we know how many LIRs eligible under the current policy have not
yet asked for a final /22?

-Peter

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

2017-09-22 Thread David Farmer

On Fri, Sep 22, 2017 at 5:04 AM, Tim Chown  wrote:

> ... and ARIN are on a last /10 policy which sees applicants get a /28 to a
> /24, so presumably those /28’s are routed at some level; that’s been in
> place for some time, how is it working out? ...
>

This ARIN policy is in section 4.10 of ARIN's NRPM;

https://www.arin.net/policy/nrpm.html#four10

This policy specifically envision the day when smaller than /24 blocks
become routable and/or there could be non-routed needs for globally unique
IPv4 addresses, in either of those cases it would be wasteful to assign a
whole /24.  Currently if a routable block is needed, which is typically the
case, ARIN's operational practice is to assign a /24.  However, if or when,
smaller blocks become generally routable, no policy change is necessary for
ARIN Staff to change it's operational practice.

Further, it should be noted that to access that pool of IPv4 resources, a
justification as to how the IPv4 addresses will be used to support the
immediate deployment of IPv6 is necessary.  Use of that pool to simply
deploy more IPv4 addresses does not conform to the intent of this policy.
Further, if an organization, already has access to IPv4 resources of any
kind, there is a strong presumption they don't need to access this pool.

Thanks

-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===

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

2017-09-22 Thread Wolfgang Zenker

On 2017-09-22 14:58:51 CET, Tom Hill wrote:
> On 22/09/17 12:11, jack _at_ k-net _dot_ pro wrote:
>> Today at $work, there is nothing planned to get rid of IPv4. Why should
>> we ? Buying some is less expensive than working on hybrid solution.

> That actually raises a good point: consider the enterprise that has
> enough IPv4 addresses for the next 30 years of company operation.
> Perhaps they manufacture really nice deck chairs, or something. They
> won't be buying any IPv4, because they don't need any more.

> Does expensive IPv4 incentivise them to switch to IPv6? No.

> Companies of this ilk exist, and in their droves. None of them
> contribute to this list because they don't care one jot, as long as the
> WWW works. Bad IPv4 connectivity needs to break their access to the WWW
> before IPv6 will be anywhere on the list of that company's activities.

We are getting there. Reachability of IPv4-only services is already degrading, 
with some(?) access carriers not operating their CGN gateways at the capacity 
needed for peak traffic times. Not least because they simply don't have enough 
IPv4 addresses to do that.

Rearding the proposed policy change I don't think it will really buy us a lot 
more time: Those members that use the existing policy to "buy" addresses by 
starting new LIRs will simply start 4 times as many new LIRs. On the other hand 
it won't do much harm either: De-aggregating of IPv4 space will continue 
anyway. So I'm undecided on the proposal.

Greetings,
Wolfgang

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

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

2017-09-22 Thread Marco Schmidt

Hello Tim,

On 2017-09-22 15:39:01 CET, Tim Chown wrote:
> There’s an argument to track and follow policies implemented elsewhere, and 
> keep in step with those. LACNIC has adopted /24 it seems, and ARIN have a /10 
> of IPv4 from which they can hand out /28 to /24. what are the current APNIC 
> or AFRINIC policies?
> 

I am happy to provide some information here.

In the AFRINIC region, in the final exhaustion phase, the minimum 
allocation/assignment size will be a /24, and the maximum will be a /22 per 
allocation/assignment.
https://www.afrinic.net/library/policies/1829-afrinic-consolidated-policy-manual#s5_4

In the APNIC region, the minimum allocation size for IPv4 is a /24.
Each APNIC account holder is eligible to receive IPv4 allocations totalling a 
maximum /22 from the APNIC 103/8 IPv4 address pool (Final /8 Block) and 
additional allocations up to a maximum of /22 address space from the APNIC 
non-103/8 IPv4 address pool.
https://www.apnic.net/community/policy/resources#Part-2:-IPv4-Policy

I hope this clarifies your question.

Kind regards,
Marco Schmidt
Policy Development Officer
RIPE NCC

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

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

Hi Tom,

> On 22 Sep 2017, at 15:37, Tom Hill  wrote:
> 
> Because I don't see a way in which this policy will change anyone's
> behaviour, or incentivise them differently over the current policy, I
> don't believe it needs to be changed. If you would like, we can take
> IPv6 adoption out of the argument completely, and I can still be solely
> against it for the reason of changing the status quo on acceptable
> prefix sizes for no perceivable gain to anyone.

The proposal doesn't have a goal of changing anyone's behaviour or 
incentivising anyone. The goal is to quadruple the number of remaining IPv4 
applications that RIPE NCC can fulfil.

So the gain is to those three quarters of applications that would otherwise be 
unsuccessful.

>> So the problem we face with the DFZ I think is not specifically
>> "smallest prefix in the table" but "growth of number of entries over
>> time." Entries over time keeps going up, and RIR policies have very
>> successfully kept that growth contained.
> 
> "I've deaggregated our /19 to /24s to prevent hijacks." is the problem.
> 
> Legitimate traffic engineering is not the issue here, it's the blatant
> disregard for the cost of TCAM across the DFZ versus the
> selfish/misguided security requirements of certain network operators.
> 
> The concern is that those persons will, very quickly, deaggregate to the
> minimum possible prefix size.

It's a fair concern; I suggest filters specific to the last /8 boundary as a 
way to contain the risk.

>> If you then fear that this deaggregation would spread to the rest of the
>> DFZ: yes, I share this fear. In fact I think we can be very sure that
>> this is coming, one way or another; Randy explained how based on history
>> earlier in the thread.
> 
> Yes, and I pointed out to Randy in response that the stakes are hell of
> a lot higher than they were in 1995. Like, "we're not the butt of all
> jokes" higher.

I hear you. I think it even supports your point in this case- if deaggregation 
could spread when the stakes were lower, we may be very sure that it'll spread 
when the stakes are higher. I hope I was able to address that point in the 
surrounding paragraphs.

Best regards,
Anna

-- 
Anna Wilson
Service Desk Manager
HEAnet CLG, Ireland’s National Education and Research Network
1st Floor, 5 George’s Dock, IFSC, Dublin D01 X8N7, Ireland
+353 (0)1 6609040   anna.wil...@heanet.iewww.heanet.ie
Registered in Ireland, No. 275301.CRA No. 20036270

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

Hi Anna,

On 22/09/17 15:05, Anna Wilson wrote:
> - that new entrants are most likely to support IPv6 (because very little
> IPv4 can be got);
> - that even fully IPv6-ed new entrants need some IPv4 to make IPv6 work;
> - reaching IPv4 runout while this is still the case will hurt those new
> entrants disproportionately;

The assertion that reducing the amount of IPv4 given will encourage
those entrants to support IPv6 is tentative at best. The LIR entrance is
a means to an end, and either it provides enough IPv4 for the task at
hand, or it does not (ergo you seek another option). A stunning number
of LIR applications are - as far as I can tell from this corner - from
those that would have otherwise applied for IPv4 PI space.

Any sane 'new entrant' (e.g. startup ISP/host) relying on the LIR
application solely isn't going to succeed. Whether you give them 1024 or
256 addresses, it's just a per-address cost. It doesn't make IPv6 any
more fit for the same purpose, or worth the engineering time at a point
where your sole concentration is on not going bust.

Because I don't see a way in which this policy will change anyone's
behaviour, or incentivise them differently over the current policy, I
don't believe it needs to be changed. If you would like, we can take
IPv6 adoption out of the argument completely, and I can still be solely
against it for the reason of changing the status quo on acceptable
prefix sizes for no perceivable gain to anyone.

> So the problem we face with the DFZ I think is not specifically
> "smallest prefix in the table" but "growth of number of entries over
> time." Entries over time keeps going up, and RIR policies have very
> successfully kept that growth contained.

"I've deaggregated our /19 to /24s to prevent hijacks." is the problem.

Legitimate traffic engineering is not the issue here, it's the blatant
disregard for the cost of TCAM across the DFZ versus the
selfish/misguided security requirements of certain network operators.

The concern is that those persons will, very quickly, deaggregate to the
minimum possible prefix size.

> If you then fear that this deaggregation would spread to the rest of the
> DFZ: yes, I share this fear. In fact I think we can be very sure that
> this is coming, one way or another; Randy explained how based on history
> earlier in the thread.

Yes, and I pointed out to Randy in response that the stakes are hell of
a lot higher than they were in 1995. Like, "we're not the butt of all
jokes" higher.

-- 
Tom

signature.asc
Description: OpenPGP digital signature

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

Hi Tom,

> On 22 Sep 2017, at 14:28, Tom Hill  wrote:
> 
> On 22/09/17 14:16, Anna Wilson wrote:
>>> 1.  It will not serve to improve IPv6 deployment
>> 
>> My memory is that the original /8 policy was implemented, not to
>> encourage/discourage IPv6 adoption among existing IPv4 holders, but
>> because we recognised that new entrants joining the internet, even when
>> IPv6 capable throughout, still require at least a little bit of IPv4.
>> Best I can tell, that's still the case.
>> 
>> So we're neutral on getting existing holders to shift, but I think this
>> proposal is highly positive on the number of new entrants who'll be able
>> to take this path.
> 
> The current 'last /8' policy is already doing what it was designed to
> do, as far as I can determine (and has been mentioned already).

Oh yes, it is, and without further intervention it will continue to do so for a 
finite amount of time, then it will stop. So the proposal is to extend that 
finite time.

> We're now beyond the time of making the 'last /8' policy, by many years,
> and I believe that we should be concentrating on making improvements to
> IPv6 - ensuring that it's an excellent future for all - instead of
> slicing IPv4 thinner. Picking-up the long tail of stubborn/disinterested
> organisations is going to be really fun.

I agree but I don't understand why this is an either/or. This proposal doesn't 
stop that work.

I'd gently suggest the counter:

- that new entrants are most likely to support IPv6 (because very little IPv4 
can be got);
- that even fully IPv6-ed new entrants need some IPv4 to make IPv6 work;
- reaching IPv4 runout while this is still the case will hurt those new 
entrants disproportionately;
- and so the worst effects fall on those who are likely to be the biggest 
supporters of IPv6 anyway.

>>> 2.  It may go as far as to seriously impact the size of the DFZ
>> 
>> I don't want to dismiss the impact that RIR policies have on the DFZ
>> (it's why we started making them, after all) but the DFZ ultimately
>> operates on its own (very raw) consensus. Fragmented blocks do work
>> today, down to /24 - and we have no idea how full runout will change the
>> dynamics of already-routed blocks.
> 
> The concern was that once the minimum size is a /24, as proposed, there
> will be a need to permit /25 or /26 announcements to permit certain
> traffic engineering strategies. Not that /22s will continued to be
> disaggregated. Disaggregation to /24 is bad enough as it is, IMO.

I take the point that the immediate pressure to deaggregate /24s could 
increase. And on the other side, Nick is pointing out what a small proportion 
of address space this proposal would affect; but nonetheless, they're both 
genuine points.

So the problem we face with the DFZ I think is not specifically "smallest 
prefix in the table" but "growth of number of entries over time." Entries over 
time keeps going up, and RIR policies have very successfully kept that growth 
contained.

Right now, the number of additional DFZ entries under the existing last /8 
policy is between 1 and 4 times the number of applications approved under that 
policy. (1 if no deaggregation, 4 if deaggregated into 4x/24.)

Even in the scenario of deaggregation down to /26, this would remain the case 
under the new proposal: 1 entry if no deaggregation, 4 if deaggregated into 
4x/26 (plus possible additional 4x deaggregation of the existing last /8 
blocks.) And if this is done on foot of a RIPE policy, then it's possible to 
manage this deaggregation in a controlled manner based on the /8 boundary.

If you then fear that this deaggregation would spread to the rest of the DFZ: 
yes, I share this fear. In fact I think we can be very sure that this is 
coming, one way or another; Randy explained how based on history earlier in the 
thread.

But in a world of run-out, I don't know how to avoid it. What I do know is that 
for as long as RIPE allocates IPv4 space, we can make policies which provide 
the routing infrastructure with some boundaries to try to manage this 
deaggregation. Once we hit full runout, we lose that ability.

Best regards,
Anna

-- 
Anna Wilson
Service Desk Manager
HEAnet CLG, Ireland’s National Education and Research Network
1st Floor, 5 George’s Dock, IFSC, Dublin D01 X8N7, Ireland
+353 (0)1 6609040   anna.wil...@heanet.iewww.heanet.ie
Registered in Ireland, No. 275301.CRA No. 20036270

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

On 22/09/17 14:40, Jan Ingvoldstad wrote:
> This just means that "certain traffic engineering strategies" will no
> longer be viable for new entrants.

In my little corner of the world, it is the flexibility of those
"traffic engineering strategies" that finally push entrants into
obtaining IP space.  I don't believe restricting that to a /24 and
making the rest of us suffer with /26 announcements is going to help the
us all in the long run.

-- 
Tom

signature.asc
Description: OpenPGP digital signature

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

2017-09-22 Thread Jan Ingvoldstad

On Fri, Sep 22, 2017 at 3:28 PM, Tom Hill  wrote:
> The concern was that once the minimum size is a /24, as proposed, there
> will be a need to permit /25 or /26 announcements to permit certain
> traffic engineering strategies. Not that /22s will continued to be
> disaggregated. Disaggregation to /24 is bad enough as it is, IMO.

"Well, actually"

This just means that "certain traffic engineering strategies" will no
longer be viable for new entrants.

-- 
Jan

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

2017-09-22 Thread Tim Chown

Hi,

> On 22 Sep 2017, at 13:56, Anna Wilson  wrote:
> 
> Hi Ray,
> 
>> On 22 Sep 2017, at 12:04, Jetten Raymond  wrote:
>> 
>> Hi Anna,
>>  
>> I saw some calculations that with the current policy it would be 4-5 years, 
>> to run completely out, last /8 and returned space.
>>  
>> Now I don’t know if these calculations are correct, but even if they are,  
>> or not, then I would like to know how long it should last ? 10 years, 20 , 
>> 50? 
>>  
>> I can see and understand your points, the original /8 proposal was not meant 
>> to delay v6, fully agree, but by spreading it now it will be expected to be 
>> spread out again in say 2-4 years (?) .
>>  
>> I seriously think that the more time we get,  or give the illusion that we 
>> can then rearrange it again, the more time people will ignore the fact that 
>> it will run out, regardless if we change the policy or not.
> 
> I believe you are correct that people will ignore runout, regardless of 
> whether we change the policy or not.
> 
> My concern is that the problems of ignoring runout fall disproportionately 
> not on existing holders who do the ignoring (who have a good chance of being 
> able to rustle up a small amount of their existing space somewhere to run 
> their IPv6 transition equipment) but on future new entrants (who would have 
> no existing space to shuffle.)
> 
> That's an externalised cost, and it is the very same externalised cost that I 
> believe the original last /8 policy was intended to address. This proposal is 
> the best way I can think to reduce that burden on new entrants.
> 
> So to answer your first question: how long should it last? My only answer to 
> that can be "for as long as new entrants need some IPv4 in order to use IPv6; 
> or as long as possible if we can't get that far." We land on /24 because we 
> think it's practical today.

But it’s not really that they "need some IPv4 in order to use IPv6”.  If 
they’re making content available, you need IPv4 whether you’re deploying 
dual-stack with IPv6 or not. If they’re deploying an IPv6-only access network, 
and using NAT64/DNS64/464XLAT to access legacy IPv4 content, then they’ll need 
less IPv4 if using IPv6, because a certain (growing) percentage of traffic will 
be native IPv6 and not NAT64’d (I see 30%-50% quoted in different scenarios, 
due to FB, Netflix, Google, etc).  The more IPv6-cabable content out there, the 
less need for IPv4 addresses for a NAT64 service.

So I think they really “need some IPv4 in order to access other people’s 
IPv4-only content". That need may drop if more NAT64 (or encapsulating 
equivalents) is deployed, or more content is directly IPv6-enabled or hosted on 
IPv6-cpable CDNs like Cloudflare, Akamai, etc.

There is some use of NAT46 (SIIT DC etc), but that seems pretty rare, at least 
currently.

>> Therefore I still think the current policy is sufficient.
> 
> Forgive me if I misunderstand your thinking; I believe it's this: that full 
> runout is the remaining tool we have to get existing IPv4 holders to deploy 
> IPv6, so we should not take further actions to delay it.
> 
> It's not an unreasonable effect to hope for. But the current /8 policy is 
> already quite restrictive. I would be surprised if full runout would have a 
> much greater effect on existing IPv4 holders. 

Perhaps holders might sell off some space if there’s complete RIR runout, the 
IPv4 price rises, and the market is the only option. So there might be a 
feedback loop which would generate more supply?

> And even if that effect is something above negligible, the burden of it falls 
> disproportionately on post-runout new entrants.
> 
> So I think that's who we need to help, and why a policy change is needed.

The aim of the proposal is very well-intentioned. I’m just not convinced it 
will make any difference by 2021/22 when the current run-out for our region is 
projected.  Things will have moved on significantly by then, just like they 
have for IPv6 between 2012 and 2017. There was effectively no IPv6 deployment 5 
years ago.

There’s an argument to track and follow policies implemented elsewhere, and 
keep in step with those. LACNIC has adopted /24 it seems, and ARIN have a /10 
of IPv4 from which they can hand out /28 to /24. what are the current APNIC or 
AFRINIC policies?

Tim

> Best regards,
> Anna
> 
> -- 
> Anna Wilson
> Service Desk Manager
> HEAnet CLG, Ireland’s National Education and Research Network
> 1st Floor, 5 George’s Dock, IFSC, Dublin D01 X8N7, Ireland
> +353 (0)1 6609040   anna.wil...@heanet.iewww.heanet.ie
> Registered in Ireland, No. 275301.CRA No. 20036270
>

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

On 22/09/17 14:16, Anna Wilson wrote:
>> 1.  It will not serve to improve IPv6 deployment
> 
> My memory is that the original /8 policy was implemented, not to
> encourage/discourage IPv6 adoption among existing IPv4 holders, but
> because we recognised that new entrants joining the internet, even when
> IPv6 capable throughout, still require at least a little bit of IPv4.
> Best I can tell, that's still the case.
> 
> So we're neutral on getting existing holders to shift, but I think this
> proposal is highly positive on the number of new entrants who'll be able
> to take this path.

The current 'last /8' policy is already doing what it was designed to
do, as far as I can determine (and has been mentioned already).

We're now beyond the time of making the 'last /8' policy, by many years,
and I believe that we should be concentrating on making improvements to
IPv6 - ensuring that it's an excellent future for all - instead of
slicing IPv4 thinner. Picking-up the long tail of stubborn/disinterested
organisations is going to be really fun.

>> 2.  It may go as far as to seriously impact the size of the DFZ
> 
> I don't want to dismiss the impact that RIR policies have on the DFZ
> (it's why we started making them, after all) but the DFZ ultimately
> operates on its own (very raw) consensus. Fragmented blocks do work
> today, down to /24 - and we have no idea how full runout will change the
> dynamics of already-routed blocks.

The concern was that once the minimum size is a /24, as proposed, there
will be a need to permit /25 or /26 announcements to permit certain
traffic engineering strategies. Not that /22s will continued to be
disaggregated. Disaggregation to /24 is bad enough as it is, IMO.

-- 
Tom

signature.asc
Description: OpenPGP digital signature

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

Hi Tom,

Thanks a lot for the thoughts.

> It's primarily because of this that I'm against 2017-03:
> 
> 1.  It will not serve to improve IPv6 deployment

My memory is that the original /8 policy was implemented, not to 
encourage/discourage IPv6 adoption among existing IPv4 holders, but because we 
recognised that new entrants joining the internet, even when IPv6 capable 
throughout, still require at least a little bit of IPv4. Best I can tell, 
that's still the case.

So we're neutral on getting existing holders to shift, but I think this 
proposal is highly positive on the number of new entrants who'll be able to 
take this path.

> 2.  It may go as far as to seriously impact the size of the DFZ

I don't want to dismiss the impact that RIR policies have on the DFZ (it's why 
we started making them, after all) but the DFZ ultimately operates on its own 
(very raw) consensus. Fragmented blocks do work today, down to /24 - and we 
have no idea how full runout will change the dynamics of already-routed blocks.

So if fragmentation of the remaining /22s in the RIPE free pool may have a 
serious impact, then I'd suggest that we need to prepare for fragmentation, 
whether or not this policy is adopted.

Of course, RIR policies do have an impact - but only for as long as the 
policies remain meaningful. Once the free pool is out, and fragmentation of 
existing blocks becomes the sole way to get more addresses, there's not much 
more we can do on this mailing list to affect the DFZ.

> 3.  I see no benefit over the current policy

So in summary: the original last /8 was meant to get new entrants onto IPv6 by 
providing them a little bit of IPv4. I'd like this to continue for longer.

Best regards,
Anna

-- 
Anna Wilson
Service Desk Manager
HEAnet CLG, Ireland’s National Education and Research Network
1st Floor, 5 George’s Dock, IFSC, Dublin D01 X8N7, Ireland
+353 (0)1 6609040   anna.wil...@heanet.iewww.heanet.ie
Registered in Ireland, No. 275301.CRA No. 20036270

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

On 22/09/17 12:11, j...@k-net.pro wrote:
> Today at $work, there is nothing planned to get rid of IPv4. Why should
> we ? Buying some is less expensive than working on hybrid solution.

That actually raises a good point: consider the enterprise that has
enough IPv4 addresses for the next 30 years of company operation.
Perhaps they manufacture really nice deck chairs, or something. They
won't be buying any IPv4, because they don't need any more.

Does expensive IPv4 incentivise them to switch to IPv6? No.

Companies of this ilk exist, and in their droves. None of them
contribute to this list because they don't care one jot, as long as the
WWW works. Bad IPv4 connectivity needs to break their access to the WWW
before IPv6 will be anywhere on the list of that company's activities.

This is _the_ business case for everyone, all the way from that
situation, to those that are full blown ISPs: IPv4 needs to stop working
before IPv6 will be considered by the vast majority of resource holders.

It's primarily because of this that I'm against 2017-03:

 1.  It will not serve to improve IPv6 deployment
 2.  It may go as far as to seriously impact the size of the DFZ
 3.  I see no benefit over the current policy

Regards,

-- 
Tom

signature.asc
Description: OpenPGP digital signature

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

Hi Ray,

> On 22 Sep 2017, at 12:04, Jetten Raymond  wrote:
> 
> Hi Anna,
>  
> I saw some calculations that with the current policy it would be 4-5 years, 
> to run completely out, last /8 and returned space.
>  
> Now I don’t know if these calculations are correct, but even if they are,  or 
> not, then I would like to know how long it should last ? 10 years, 20 , 50? 
>  
> I can see and understand your points, the original /8 proposal was not meant 
> to delay v6, fully agree, but by spreading it now it will be expected to be 
> spread out again in say 2-4 years (?) .
>  
> I seriously think that the more time we get,  or give the illusion that we 
> can then rearrange it again, the more time people will ignore the fact that 
> it will run out, regardless if we change the policy or not.

I believe you are correct that people will ignore runout, regardless of whether 
we change the policy or not.

My concern is that the problems of ignoring runout fall disproportionately not 
on existing holders who do the ignoring (who have a good chance of being able 
to rustle up a small amount of their existing space somewhere to run their IPv6 
transition equipment) but on future new entrants (who would have no existing 
space to shuffle.)

That's an externalised cost, and it is the very same externalised cost that I 
believe the original last /8 policy was intended to address. This proposal is 
the best way I can think to reduce that burden on new entrants.

So to answer your first question: how long should it last? My only answer to 
that can be "for as long as new entrants need some IPv4 in order to use IPv6; 
or as long as possible if we can't get that far." We land on /24 because we 
think it's practical today.

> Therefore I still think the current policy is sufficient.

Forgive me if I misunderstand your thinking; I believe it's this: that full 
runout is the remaining tool we have to get existing IPv4 holders to deploy 
IPv6, so we should not take further actions to delay it.

It's not an unreasonable effect to hope for. But the current /8 policy is 
already quite restrictive. I would be surprised if full runout would have a 
much greater effect on existing IPv4 holders. And even if that effect is 
something above negligible, the burden of it falls disproportionately on 
post-runout new entrants.

So I think that's who we need to help, and why a policy change is needed.

Best regards,
Anna

-- 
Anna Wilson
Service Desk Manager
HEAnet CLG, Ireland’s National Education and Research Network
1st Floor, 5 George’s Dock, IFSC, Dublin D01 X8N7, Ireland
+353 (0)1 6609040   anna.wil...@heanet.iewww.heanet.ie
Registered in Ireland, No. 275301.CRA No. 20036270

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

2017-09-22 Thread jack

This proposal will increase per-IP price
Thus, it will promote alternatives (IPv6 !)

Today at $work, there is nothing planned to get rid of IPv4. Why should
we ? Buying some is less expensive than working on hybrid solution.

On 22/09/2017 13:04, Jetten Raymond wrote:
> I seriously think that the more time we get,  or give the illusion that we 
> can then rearrange it again, the more time people will ignore the fact that 
> it will run out, regardless if we change the policy or not.




-- 
Jack
Net/sys admin

More details about KWAOO can be found at:
https://as24904.kwaoo.net/



signature.asc
Description: OpenPGP digital signature

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

2017-09-22 Thread Martin Huněk

Hello,

I don't think that there is anyone whom would not be able to justify /22. So I 
think that there should not be any need for justification. Simply because it 
would be one more meaningless paper, nothing more.

Secondly, for me having more specific routes than /24 doesn't seems seem as the 
right solution for IPv4. More specific routes means more routes in table, so 
more resources spent on legacy protocol.

As for the core of the proposal - droping maximal allocation size from /22 to 
/24: I don't think that keeping PA pool longer than needed is good for future 
of an Internet.

Maybe it would be better to transfer more space in PI IX pool, drop the 
restrictions on that pool which prevents to use it for CGN and let the PA 
space run flat.

Long story short, I'm aginst the 2017-03 policy as it is written right now.

Best Regards,
Martin Hunek

Dne pátek 22. září 2017 10:09:28 CEST, Daniel Suchy napsal(a):
> Hello,
> /24 is de-facto standard accepted in routing tables these days and also
> /24 was used in large scale during PI assignments - so I don't see any
> problem in reduction of initial (minimal) IPv4 allocation. So i support
> this idea.
>
> But I would like to keep option for asking more than /24 (up to /22
> maximum, as was decided in the past) LIRs eligible for allocation, if
> LIR properly documents his request.
>
> From my own practice there're some LIR, where /24 is sufficient and they
> just become LIRs because there's no other real option to get independent
> addresses (old "PI") and with /22 we're just wasting limited resource.
> But there're also LIRs, where /22 will actively used.
>
> I don't see any problems in terms of RFC 2050 mentioned here and memory
> contraints, providers had to upgrade their routers in meantime anyway
> (at least due to IPv6 adoption). Fragmentation up to /24 is long-term
> reality and we had to deal with it anyway.
>
> With regards,
> Daniel
>
> On 09/21/2017 01:43 PM, Marco Schmidt wrote:
> > Dear colleagues,
> >
> > A new RIPE Policy proposal, 2017-03, "Reducing Initial IPv4 Allocation,
> > aiming to preserve a minimum of IPv4 space", is now available for
> > discussion.
> >
> > The goal of this proposal is to reduce the IPv4 allocations made by the
> > RIPE NCC to a /24 (currently a /22) and only to LIRs that have not
> > received an IPv4 allocation directly from the RIPE NCC before.
> >
> > You can find the full proposal at:
> > https://www.ripe.net/participate/policies/proposals/2017-03/
> >
> > As per the RIPE Policy Development Process (PDP), the purpose of this
> > four-week Discussion Phase is to discuss the proposal and provide feedback
> > to the proposer.
> >
> > At the end of the Discussion Phase, the proposer, with the agreement of
> > the RIPE Working Group Chairs, decides how to proceed with the proposal.
> >
> > We encourage you to review this proposal and send your comments to
> >  before 20 October 2017.
> >
> > Kind regards,
> >
> > Marco Schmidt
> > Policy Development Officer
> > RIPE NCC
> >
> > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

signature.asc
Description: This is a digitally signed message part.

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

2017-09-22 Thread Jetten Raymond

Hi Rob,

The killer app : Most companies want to grow, especially those that serve 
shareholders, so imho expandability is the "app" .

— these are the last bits of IPv4, here is your slice, it’s the same for all 
newcomers.  We are in the end-game.

Indeed, we have been there for a while, making it longer will not change 
behavior as you concluded earlier in your message.

Rgds,

Ray

-Original Message-
From: address-policy-wg [mailto:address-policy-wg-boun...@ripe.net] On Behalf 
Of Rob Evans
Sent: 22. syyskuuta 2017 14:48
To: address-policy-wg@ripe.net
Subject: Re: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial 
IPv4 Allocation, aiming to preserve a minimum of IPv4 space)

Hi all,

I think it’s worth remembering that there is a time lag between policies being 
implemented and them having an effect on the market.

Forgive me if I go into a bit of speculation, but where would we be if RIRs 
hadn’t implemented a “last /8” policy?  The RIPE NCC’s coffers would almost 
certainly be dry and the only realistic means of obtaining IPv4 addresses would 
be through the open market.  The price would be higher than it is now, but 
would IPv6 deployment be any higher?  Existing companies would be in the same 
situation they are in now, with no more incentive to deploy IPv6 (where is that 
killer app?), and some small companies would not have been able to get off the 
ground.

What this policy is trying to do is get around that fact that a lot of the 
industry (probably not the ones on this list) still have their head in the sand 
as far as IPv4 depletion goes.  It’s “I’m alright Jack”, and it is taking 
longer than anyone expected to get the message across.  I’m not convinced 
running dry is going to change that.

However, the message is getting across, slowly but surely, and IPv6 adoption is 
growing not just among the sort of people that participate in these discussions 
and network operator fora, but in the enterprise networks and even hotel and 
cafe wireless networks.

We have to believe we will get there in the end, but we need to make sure we 
have the resources to get there, it’s too late to change policies when we are 
already out of addresses.  If we ran out of IPv4 resources today, will it 
change the IPv6 deployment plans of those that already have IPv4?  What will be 
different for them compared to the situation where we keep some dregs of IPv4 
for new entrants to the market?  The fact that *they* can’t get any more 
addresses from the NCC?  That’s no different to the situation now.

I would dearly love to see the end of IPv4 policies, and perhaps I’d prefer 
this policy if it had a sliding scale that changed the initial allocation size 
based on what was left in the NCC’s resource pool, but that might be too 
arbitrary — then again /22 and /24 are also, to some extent, arbitrary.  
Dropping down to the minimum currently routed size makes quite a bit of sense — 
these are the last bits of IPv4, here is your slice, it’s the same for all 
newcomers.  We are in the end-game.

Cheers,
Rob

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

2017-09-22 Thread Rob Evans

Hi all,

I think it’s worth remembering that there is a time lag between policies being 
implemented and them having an effect on the market.

Forgive me if I go into a bit of speculation, but where would we be if RIRs 
hadn’t implemented a “last /8” policy?  The RIPE NCC’s coffers would almost 
certainly be dry and the only realistic means of obtaining IPv4 addresses would 
be through the open market.  The price would be higher than it is now, but 
would IPv6 deployment be any higher?  Existing companies would be in the same 
situation they are in now, with no more incentive to deploy IPv6 (where is that 
killer app?), and some small companies would not have been able to get off the 
ground.

What this policy is trying to do is get around that fact that a lot of the 
industry (probably not the ones on this list) still have their head in the sand 
as far as IPv4 depletion goes.  It’s “I’m alright Jack”, and it is taking 
longer than anyone expected to get the message across.  I’m not convinced 
running dry is going to change that.

However, the message is getting across, slowly but surely, and IPv6 adoption is 
growing not just among the sort of people that participate in these discussions 
and network operator fora, but in the enterprise networks and even hotel and 
cafe wireless networks.

We have to believe we will get there in the end, but we need to make sure we 
have the resources to get there, it’s too late to change policies when we are 
already out of addresses.  If we ran out of IPv4 resources today, will it 
change the IPv6 deployment plans of those that already have IPv4?  What will be 
different for them compared to the situation where we keep some dregs of IPv4 
for new entrants to the market?  The fact that *they* can’t get any more 
addresses from the NCC?  That’s no different to the situation now.

I would dearly love to see the end of IPv4 policies, and perhaps I’d prefer 
this policy if it had a sliding scale that changed the initial allocation size 
based on what was left in the NCC’s resource pool, but that might be too 
arbitrary — then again /22 and /24 are also, to some extent, arbitrary.  
Dropping down to the minimum currently routed size makes quite a bit of sense — 
these are the last bits of IPv4, here is your slice, it’s the same for all 
newcomers.  We are in the end-game.

Cheers,
Rob

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

2017-09-22 Thread Jim Reid

> On 22 Sep 2017, at 12:11, n...@kwaoo.net wrote:
> 
> Today at $work, there is nothing planned to get rid of IPv4. Why should
> we ? Buying some is less expensive than working on hybrid solution.

So what? How could a change in the current v4 address policy possibly change 
that behaviour?

If your company can’t/won’t prepare for the inevitable, you only have 
yourselves to blame.

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

2017-09-22 Thread Jetten Raymond

Hi Anna,

I saw some calculations that with the current policy it would be 4-5 years, to 
run completely out, last /8 and returned space.

Now I don’t know if these calculations are correct, but even if they are,  or 
not, then I would like to know how long it should last ? 10 years, 20 , 50?

I can see and understand your points, the original /8 proposal was not meant to 
delay v6, fully agree, but by spreading it now it will be expected to be spread 
out again in say 2-4 years (?) .

I seriously think that the more time we get,  or give the illusion that we can 
then rearrange it again, the more time people will ignore the fact that it will 
run out, regardless if we change the policy or not.

Therefore I still think the current policy is sufficient.

Rgds,

Ray


From: Anna Wilson [mailto:anna.wil...@heanet.ie]
Sent: 22. syyskuuta 2017 13:32
To: Jetten Raymond 
Cc: address-policy-wg@ripe.net
Subject: Re: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial 
IPv4 Allocation, aiming to preserve a minimum of IPv4 space)

Hello Ray,

On 22 Sep 2017, at 10:40, Jetten Raymond 
> wrote:
I Oppose this 2017-03 proposal,

IPv6 has been around for decades, and "we" have failed to implement it in time. 
I see no point in rewarding laziness and yet trying to again give more time to 
seriously start to implement v6. The more time we are given, the more time it 
will take, that’s how we have done it in the past, and I don’t see the laziness 
go if not forced to. Warnings were ignored, we (v6 advocates) were laughed at, 
"again it will end", " you’ve told us that many years". Even if we only hand 
out a /28, we still have the basic problem, and it won't go away v4 WILL run 
out. Don’t make the suffering any longer.

I'm a co-author of the proposal... and I agree with you, in as much that 
postponing efforts to deploy v6 is rewarding the wrong thing.

But I don't recall that being the goal of the original last /8 proposal at all.

Our observations are:
- in order for new entrants to deploy v6 at all, they currently need a little 
bit of v4
- this fact is probably not going to change between now and the 
currently-expected runout of the last /8

So, just like the original last /8 proposal, I believe that this is a pro-v6 
proposal. All that's changed between the original last /8 proposal and now is 
that we now have a picture of the run-rate of the last /8.

So this proposal is to give more new entrants the chance to join the v6 
internet - with the bit of v4 they need to do that - instead of allowing the 
rest of us to externalise the cost of v4 runout even further.

Best regards,
Anna

--
Anna Wilson
Service Desk Manager
HEAnet CLG, Ireland’s National Education and Research Network
1st Floor, 5 George’s Dock, IFSC, Dublin D01 X8N7, Ireland
+353 (0)1 6609040   anna.wil...@heanet.ie
www.heanet.ie
Registered in Ireland, No. 275301.CRA No. 20036270

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

On 21/09/17 20:22, Randy Bush wrote:
> once it was /19.  welcome to life.

I think the stakes are a little higher these days.

-- 
Tom Hill
Network Manager

Bytemark Hosting
http://www.bytemark.co.uk/
tel. +44 1904 890 890



signature.asc
Description: OpenPGP digital signature

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

2017-09-22 Thread Tim Chown

> On 22 Sep 2017, at 05:50, Mikael Abrahamsson  wrote:
> 
> On Thu, 21 Sep 2017, Tim Chown wrote:
> 
>>> At the current run-rate, do we know what is the expected expiry of the free 
>>> pool in RIPE's hands?
>> 
>> There’s http://www.potaroo.net/tools/ipv4/.
> 
> There is also:
> 
> https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion/ipv4-available-pool-graph
> 
> Looks to me that there is still IPv4 space being returned, the run-rate on 
> 185/8 is constant, we have approximately 4-5 years to go?
> 
> To me it looks like things are going according to plan, and I don't see any 
> need to change anything.

I’d agree with that.

The proposal does no analysis of the “run rate” of consumption, or other the 
impact of other RIR policies.  I’d like to see that presented.

Looking at https://www.ripe.net/participate/policies/proposals/2017-03/, it 
seems that LACNIC have moved from a /22 to a /24 policy last month (so hard to 
measure impact yet), and ARIN are on a last /10 policy which sees applicants 
get a /28 to a /24, so presumably those /28’s are routed at some level; that’s 
been in place for some time, how is it working out?  What about APNIC and 
AFRINIC?

The current run-out projection is 2021/22, five years away. Consider where IPv6 
deployment was 5 years ago.  Since then we’ve gone from ~0% deployment 
worldwide to ~20%, and seen a wide range of ISPs and content providers deploy, 
and importantly the bigger CDNs now provide dual-stack by default out-of the 
box.  Consider where we’ll be in 5 years from now.

Tim

PS. Seeing “more members” as a benefit is a strange advantage to add in the 
proposal, given these are implicitly people gaming the system?

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

2017-09-22 Thread Tim Chown

> On 22 Sep 2017, at 08:18, Randy Bush  wrote:
> 
> 
> 
> when v4 runout forces folk to put /28s in frnt of nats, the folk with
> shiny shoes will have a little chat with senior leadership, and they'll
> cough up the bucks to hold the routes.  history repeats.

Doesn’t the ARIN policy potentially mean applicants will get a /28?  Are those 
being filtered, or aggregated locally to avoid that?

See https://www.arin.net/policy/nrpm.html#four10

Tim

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

2017-09-22 Thread Arash Naderpour

Hi Carlos,


>>
>   This proposal is not aimed at preventing the complete runout. That
>> will happen. This proposal aims to preserve some tiny resources for new
>> entrants in
>>   this community, by trying to extend the time period until the
>> runout occurs. We cannot "measure" its benefits until the runout occurs,
>> and we can then
>>   count how many new entrants did get a tiny portion of (new, never
>> used before) IPv4 address space.
>>
>>
>> The current policy without this change is doing the same, preserving tiny
>> resources (/22) for new entrants.
>> You are saying that there are some benefit and we cannot measure them
>> now, but lets do it, am I right?
>>
>
> I'm saying there is an obvious benefit: accomodate more new entrants.
>
> Because an org is able to have/open multiple LIRs, the real new entrants
> number is not really easy to calculate :-)
>
>
My understanding from this proposal is that it just change the allocation
size but an org is still able to have/open multi LIRs,

If this proposal reach consensus, someone still can open four LIRs and get
the same amount of IP address as now. The difference (from technical point
of view) is that we may have less entry in routing tables with an /22
allocation but with this proposal we will have for sure 4x /24 entry
without gaining that much.


Regards,

Arash





>
>
> Regards,
>>
>> Arash
>>
>>
>>
>>
>>
>>
>>
>> Arash
>>
>>
>>
>> On Fri, Sep 22, 2017 at 12:34 AM, Tim Chown <
>> t...@ecs.soton.ac.uk> wrote:
>>   > On 21 Sep 2017, at 13:33, Aled Morris <
>> aled.w.mor...@googlemail.com> wrote:
>>   >
>>   > On 21 September 2017 at 12:43, Marco Schmidt <
>> mschm...@ripe.net> wrote:
>>   > The goal of this proposal is to reduce the IPv4
>> allocations made by the RIPE NCC
>>   > to a /24 (currently a /22) and only to LIRs that have
>> not received an IPv4 allocation
>>   > directly from the RIPE NCC before.
>>   >
>>   > At the current run-rate, do we know what is the
>> expected expiry of the free pool in RIPE's hands?
>>
>>   There?s http://www.potaroo.net/tools/ipv4/.
>>
>>   Tim
>>
>>
>>
>>
>>
>>

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

2017-09-22 Thread Jim Reid

> On 22 Sep 2017, at 08:58, n...@kwaoo.net wrote:
> 
> Maybe the right path is to find some way to allocate those addresses to
> real new entrants only

Come up with a viable definition “new real entrant”. It’s not as easy as you 
seem to think it is.

> Perhaps limitations like only one allocation:
> - per LIR
> - per legal entity
> - per physical person
> - per "network", "activity" or whatever, & based on how you should have
> your own resources

Now consider how that can be policed. How much is that going to cost? Will the 
NCC have to buy a DNA sequencer and demand samples from anyone wanting address 
space? [And what about identical twins?] BTW every LIR is a legal entity and 
can only get exactly one v4 allocation under the current policy.

> Anything that can allow the RIPE to say : "nope, you're obviously trying
> to get more stuff from us, you got your part, we deny this allocation”

This should already be happening. Though there may well be unscrupulous people 
who look for and maybe find ways to manipulate the system. No IPv4 allocation 
policy is perfect or foolproof. The one we’ve got is good enough. It doesn’t 
need fixing.

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

2017-09-22 Thread Jan Ingvoldstad

On Thu, Sep 21, 2017 at 1:43 PM, Marco Schmidt  wrote:
> Dear colleagues,
>
> A new RIPE Policy proposal, 2017-03, "Reducing Initial IPv4 Allocation,
> aiming to preserve a minimum of IPv4 space", is now available for discussion.
>
> The goal of this proposal is to reduce the IPv4 allocations made by the RIPE 
> NCC
> to a /24 (currently a /22) and only to LIRs that have not received an IPv4 
> allocation
> directly from the RIPE NCC before.
>
> You can find the full proposal at:
> https://www.ripe.net/participate/policies/proposals/2017-03/

As laid out, I think this proposal makes sense, and is also presented
in due time before it strictly becomes necessary. That's good.

An IPv4 allocation of this size (and even less, 32 addresses, but,
graaahgh, routing) makes sense to ensure that there can be new
entrants for a long time to come, and doesn't seem overly burdensome
for new entrants.
-- 
Jan

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

2017-09-22 Thread noc

Yes

I agree with your proposal

Regards,

On 22/09/2017 10:21, Carlos Friaças wrote:
> 
> Hi,
> 
> <2017-03 co-author hat on>
> 
> "Access" is not the aim of this policy proposal.
> 
> Afaik, there was already a proposal which had some common points with
> what is described below, and it didn't get anywhere then.
> 
> Regards,
> Carlos Friaças
> 
> 
> 
> On Fri, 22 Sep 2017, n...@kwaoo.net wrote:
> 
>> Maybe the right path is to find some way to allocate those addresses to
>> real new entrants only
>>
>> Perhaps limitations like only one allocation:
>> - per LIR
>> - per legal entity
>> - per physical person
>> - per "network", "activity" or whatever, & based on how you should have
>> your own resources
>>
>> Anything that can allow the RIPE to say : "nope, you're obviously trying
>> to get more stuff from us, you got your part, we deny this allocation"
>>
>> This way, the last ressources' purpose will be filled properly, and not
>> scavenged by greedy guys
>>
>> Regards,
>>
>> On 22/09/2017 09:04, Carlos Friaças wrote:
>>> This proposal is not aimed at preventing the complete runout. That will
>>> happen. This proposal aims to preserve some tiny resources for new
>>> entrants in this community, by trying to extend the time period until
>>> the runout occurs. We cannot "measure" its benefits until the runout
>>> occurs, and we can then count how many new entrants did get a tiny
>>> portion of (new, never used before) IPv4 address space.
>>
>> -- 
>> Jack
>> Net/sys admin
>>
>> More details about KWAOO can be found at:
>> https://as24904.kwaoo.net/
>>


-- 
Jack
Kwaoo noc

More details about KWAOO can be found at:
https://as24904.kwaoo.net/

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

2017-09-22 Thread Carlos Friaças



Hi,

<2017-03 co-author hat on>

"Access" is not the aim of this policy proposal.

Afaik, there was already a proposal which had some common points with 
what is described below, and it didn't get anywhere then.


Regards,
Carlos Friaças



On Fri, 22 Sep 2017, n...@kwaoo.net wrote:


Maybe the right path is to find some way to allocate those addresses to
real new entrants only

Perhaps limitations like only one allocation:
- per LIR
- per legal entity
- per physical person
- per "network", "activity" or whatever, & based on how you should have
your own resources

Anything that can allow the RIPE to say : "nope, you're obviously trying
to get more stuff from us, you got your part, we deny this allocation"

This way, the last ressources' purpose will be filled properly, and not
scavenged by greedy guys

Regards,

On 22/09/2017 09:04, Carlos Friaças wrote:

This proposal is not aimed at preventing the complete runout. That will
happen. This proposal aims to preserve some tiny resources for new
entrants in this community, by trying to extend the time period until
the runout occurs. We cannot "measure" its benefits until the runout
occurs, and we can then count how many new entrants did get a tiny
portion of (new, never used before) IPv4 address space.


--
Jack
Net/sys admin

More details about KWAOO can be found at:
https://as24904.kwaoo.net/

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

2017-09-22 Thread Carlos Friaças

On Fri, 22 Sep 2017, Arash Naderpour wrote:

Hi Carlos,

Hi,

  This proposal is not aimed at preventing the complete runout. That will 
happen. This proposal aims to preserve some tiny resources for new entrants in
  this community, by trying to extend the time period until the runout occurs. We 
cannot "measure" its benefits until the runout occurs, and we can then
  count how many new entrants did get a tiny portion of (new, never used 
before) IPv4 address space.

The current policy without this change is doing the same, preserving tiny 
resources (/22) for new entrants. 
You are saying that there are some benefit and we cannot measure them now, but 
lets do it, am I right?

I'm saying there is an obvious benefit: accomodate more new entrants.

Because an org is able to have/open multiple LIRs, the real new entrants 
number is not really easy to calculate :-)

Even if there is a need, it could be 3x/24 or /23.why change it 
from /22 to /24?

  Yes, a /23+/24 or a /23 would be a step in the right direction. If, at 
global level, a /25 or a /26 was acceptable (routing-wise), then that would be
  even better. 

   I would also like to draw your attention to the last section about "Alignment 
with other RIRs": LACNIC already has this in place. ARIN has something,
  which isn't really exactly the same, but the main goal is very similar. 
:-)

Still unanswered, why /24 not a /23+/24 or a /23?

Going to a /24 will potentially accomodate more new entrants than a /23 or 
a /23+/24, and definitely more than the currently /22.

A /25 or a /26 are not feasible as of today. Not sure if it will ever be.

what is the benefit of this "Alignment with other RIRs" to the RIPE community? 
I don't see any need for that too. 

Just to let everyone know we are not "innovating" nothing here. Different 
communities already took this step towards extending the period where "new 
entrants" are able to get some IPv4 address space.

Regards,
Carlos Friaças

Regards,

Arash

Arash

On Fri, Sep 22, 2017 at 12:34 AM, Tim Chown  
wrote:
      > On 21 Sep 2017, at 13:33, Aled Morris 
 wrote:
      >
      > On 21 September 2017 at 12:43, Marco Schmidt 
 wrote:
      > The goal of this proposal is to reduce the IPv4 allocations 
made by the RIPE NCC
      > to a /24 (currently a /22) and only to LIRs that have not 
received an IPv4 allocation
      > directly from the RIPE NCC before.
      >
      > At the current run-rate, do we know what is the expected 
expiry of the free pool in RIPE's hands?

      There?s http://www.potaroo.net/tools/ipv4/.

      Tim

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

2017-09-22 Thread Jim Reid


> On 22 Sep 2017, at 08:08, Randy Bush  wrote:
> 
> oppressing the proletariat did not work out too randy

I’m not sure randiness was affected either way by the oppression of the 
proletariat. :-)

Sorry. Couldn’t resist.

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

2017-09-22 Thread Daniel Suchy

Hello,
/24 is de-facto standard accepted in routing tables these days and also
/24 was used in large scale during PI assignments - so I don't see any
problem in reduction of initial (minimal) IPv4 allocation. So i support
this idea.

But I would like to keep option for asking more than /24 (up to /22
maximum, as was decided in the past) LIRs eligible for allocation, if
LIR properly documents his request.

>From my own practice there're some LIR, where /24 is sufficient and they
just become LIRs because there's no other real option to get independent
addresses (old "PI") and with /22 we're just wasting limited resource.
But there're also LIRs, where /22 will actively used.

I don't see any problems in terms of RFC 2050 mentioned here and memory
contraints, providers had to upgrade their routers in meantime anyway
(at least due to IPv6 adoption). Fragmentation up to /24 is long-term
reality and we had to deal with it anyway.

With regards,
Daniel

On 09/21/2017 01:43 PM, Marco Schmidt wrote:
> Dear colleagues,
> 
> A new RIPE Policy proposal, 2017-03, "Reducing Initial IPv4 Allocation,
> aiming to preserve a minimum of IPv4 space", is now available for discussion.
> 
> The goal of this proposal is to reduce the IPv4 allocations made by the RIPE 
> NCC
> to a /24 (currently a /22) and only to LIRs that have not received an IPv4 
> allocation
> directly from the RIPE NCC before.
> 
> You can find the full proposal at:
> https://www.ripe.net/participate/policies/proposals/2017-03/
> 
> As per the RIPE Policy Development Process (PDP), the purpose of this
> four-week Discussion Phase is to discuss the proposal and provide feedback to 
> the proposer.
> 
> At the end of the Discussion Phase, the proposer, with the agreement of
> the RIPE Working Group Chairs, decides how to proceed with the proposal.
> 
> We encourage you to review this proposal and send your comments to
>  before 20 October 2017.
> 
> Kind regards,
> 
> Marco Schmidt
> Policy Development Officer
> RIPE NCC
> 
> Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
>

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

2017-09-22 Thread Dominik Nowacki

I agree with Mikael.

It all goes again and again.

I don’t see a need to change the current policy. Especially not to reduce the 
assignment.

There has to come a time for the IP4 to finish at RIR level before pressure 
builds up on Ip6 rollout for those who didn’t bother to date. I don’t believe 
prolonging this even further serves the interest the community better, it does 
however serves the interest of brokers and rouge LIRs selling ‘Virgin, never 
used blocks’ on the market today by increasing their profits.

I’m against this proposal.

With Kind Regards,
Dominik Nowacki

Clouvider Limited is a limited company registered in England and Wales. 
Registered number: 08750969. Registered office: 88 Wood Street, 
London, United Kingdom, EC2V 7RS. Please note that Clouvider Limited may 
monitor email traffic data and also the content of email for the purposes of 
security and staff training. This message contains confidential information and 
is intended only for the intended recipient. If you do not believe you are the 
intended recipient you should not disseminate, distribute or copy this e-mail. 
Please notify ab...@clouvider.net of this e-mail 
immediately by e-mail if you have received this e-mail by mistake and delete 
this e-mail from your system. E-mail transmission cannot be guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or contain viruses. Clouvider Limited nor 
any of its employees therefore does not accept liability for any errors or 
omissions in the contents of this message, which arise as a result of e-mail 
transmission. If verification is required please request a hard-copy version.

On 22 Sep 2017, at 08:53, Mikael Abrahamsson 
> wrote:

On Fri, 22 Sep 2017, Randy Bush wrote:

people will say all sorts of stupid things; funny monkeys we are.  this does 
not mean we should use technology to teach morality lessons.  it has not worked 
out too well when tried.

My point is that it's useless to prolong the agony. The more we do, the longer 
people will procrastinate, and the more painful it becomes. /22 is a good 
tradeoff between the different goals here. It was a good tradeoff when it was 
implemented, I see it still being a good tradeoff 3 years from now.

--
Mikael Abrahamssonemail: swm...@swm.pp.se

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

2017-09-22 Thread noc

Maybe the right path is to find some way to allocate those addresses to
real new entrants only

Perhaps limitations like only one allocation:
- per LIR
- per legal entity
- per physical person
- per "network", "activity" or whatever, & based on how you should have
your own resources

Anything that can allow the RIPE to say : "nope, you're obviously trying
to get more stuff from us, you got your part, we deny this allocation"

This way, the last ressources' purpose will be filled properly, and not
scavenged by greedy guys

Regards,

On 22/09/2017 09:04, Carlos Friaças wrote:
> This proposal is not aimed at preventing the complete runout. That will
> happen. This proposal aims to preserve some tiny resources for new
> entrants in this community, by trying to extend the time period until
> the runout occurs. We cannot "measure" its benefits until the runout
> occurs, and we can then count how many new entrants did get a tiny
> portion of (new, never used before) IPv4 address space.

--
Jack
Net/sys admin

More details about KWAOO can be found at:
https://as24904.kwaoo.net/

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

2017-09-22 Thread Mikael Abrahamsson


On Fri, 22 Sep 2017, Randy Bush wrote:

people will say all sorts of stupid things; funny monkeys we are.  this 
does not mean we should use technology to teach morality lessons.  it 
has not worked out too well when tried.


My point is that it's useless to prolong the agony. The more we do, the 
longer people will procrastinate, and the more painful it becomes. /22 is 
a good tradeoff between the different goals here. It was a good tradeoff 
when it was implemented, I see it still being a good tradeoff 3 years from 
now.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

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

2017-09-22 Thread Arash Naderpour

Hi Carlos,


>
> This proposal is not aimed at preventing the complete runout. That will
> happen. This proposal aims to preserve some tiny resources for new entrants
> in this community, by trying to extend the time period until the runout
> occurs. We cannot "measure" its benefits until the runout occurs, and we
> can then count how many new entrants did get a tiny portion of (new, never
> used before) IPv4 address space.


The current policy without this change is doing the same, preserving tiny
resources (/22) for new entrants.
You are saying that there are some benefit and we cannot measure them now,
but lets do it, am I right?


> Even if there is a need, it could be 3x/24 or /23.why change it from /22
>> to /24?
>>
>
> Yes, a /23+/24 or a /23 would be a step in the right direction. If, at
> global level, a /25 or a /26 was acceptable (routing-wise), then that would
> be even better.

 I would also like to draw your attention to the last section about
> "Alignment with other RIRs": LACNIC already has this in place. ARIN has
> something, which isn't really exactly the same, but the main goal is very
> similar. :-)
>


Still unanswered, why /24 not a /23+/24 or a /23?
what is the benefit of this "Alignment with other RIRs" to the RIPE
community? I don't see any need for that too.

Regards,

Arash








> Arash
>>
>>
>>
>> On Fri, Sep 22, 2017 at 12:34 AM, Tim Chown  wrote:
>>   > On 21 Sep 2017, at 13:33, Aled Morris <
>> aled.w.mor...@googlemail.com> wrote:
>>   >
>>   > On 21 September 2017 at 12:43, Marco Schmidt 
>> wrote:
>>   > The goal of this proposal is to reduce the IPv4 allocations made
>> by the RIPE NCC
>>   > to a /24 (currently a /22) and only to LIRs that have not
>> received an IPv4 allocation
>>   > directly from the RIPE NCC before.
>>   >
>>   > At the current run-rate, do we know what is the expected expiry
>> of the free pool in RIPE's hands?
>>
>>   There?s http://www.potaroo.net/tools/ipv4/.
>>
>>   Tim
>>
>>
>>
>>

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

> Then they have to buy addresses in the market. I keep running into
> people who claim "look, RIPE is not out of IPv4 addresses, the IPv4
> exhaustion is just a hype/FUD".

people will say all sorts of stupid things; funny monkeys we are.  this
does not mean we should use technology to teach morality lessons.  it
has not worked out too well when tried.

> They won't stop until RIPE is really out.

and of course they will find nothing else to complain about, accuse, try
to scam, ...  and cash will fall from the sky.

randy

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

2017-09-22 Thread Carlos Friaças

On Fri, 22 Sep 2017, Aleksey Bulgakov wrote:

Hi.

Hi,

I think it would be better to allocate /19 or bigger. It helps to go to
IPv6 and the problem of IPv4 is resolved automatically.

I'm really not sure about that. It won't solve any new entrant's case.

I'm working around IPv6 since 2001. Anna and Randy probably since before
that. We have deployed IPv6. It didn't enable us to completely get rid of
IPv4 within our networks. That also didn't solve any issue for 3rd party
networks -- they all still need IPv4 addresses.

I don't really understand why the NCC tries to prolong the life of the
dead patient by means of restrictions such as 2015-01, 2017-03 and
others.

Please note 2017-03 is not approved yet.
Please also note that the NCC is not authoring this proposal.

There was a presentation about this issue in Budapest at RIPE 72. Randy
talked about building a new proposal then, and it took some months to put
it together. :-)

It seems the NCC wants to earn money due to the IPs become more
expensive.

I don't really think this is the case. The main goal here is to preserve a
minimal chunk of space for new entrants. And today, a /24 is the "minimal
acceptable" size for that.

So I oppose this proposal.

Noted.

Regards,
Carlos Friaças

22 ???2017 ?.7:50 "Mikael Abrahamsson" ???:
On Thu, 21 Sep 2017, Tim Chown wrote:

At the current run-rate, do we know what is the expected
expiry of the free pool in RIPE's hands?

There?s http://www.potaroo.net/tools/ipv4/.

There is also:

https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion/ipv4-available-pool-graph

Looks to me that there is still IPv4 space being returned, the run-rate on
185/8 is constant, we have approximately 4-5 years to go?

To me it looks like things are going according to plan, and I don't see any
need to change anything.

--
Mikael Abrahamsson email: swm...@swm.pp.se

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

2017-09-22 Thread Mikael Abrahamsson


On Fri, 22 Sep 2017, Randy Bush wrote:


Looks to me that there is still IPv4 space being returned, the
run-rate on 185/8 is constant, we have approximately 4-5 years to go?


and you believe that there will be zero desirable ipv4 destinations on the
internet by then?  sure does not look like it as far as i can see.


I agree.


and if a new entrant needs to reach the remaining ipv4 internet, ...?


Then they have to buy addresses in the market. I keep running into people 
who claim "look, RIPE is not out of IPv4 addresses, the IPv4 exhaustion is 
just a hype/FUD". They won't stop until RIPE is really out. If this 
happens in 4-5 years, I'm fine with that. That means they had 8-10 years 
from we actually ran out to understand.


We (the RIPE community) has had a quite balanced and approach to this and 
enabled new entrants in the mean time. We can't stretch this out forever. 
The stone is bled dry, and that's just the way it is.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

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

a bit of history for those with short term vision

1995, and large providers were running out of ram to hold the table.
sprint was the closest to the edge and falling over; but others were
not far behind and could smell the coffee.  these were the days
where we all intimately knew each others' networks.

nobody's management was gonna pay to upgrade hundreds of routers.
sean had to filter to keep from crashing.  others, such as asp and
i, were also filtering, as much to keep the table down as to protect
from idiots such as vinnie from killing us (7007 incident).

so the providers who were concerned and the rirs met at the danvers
ietf and agreed to only let /19s and shorter, and swamp space /24s,
through if the rirs would please not allocate longer prefixes for a
couple of years until routers could be upgraded.  rfc 2050 was the
result.

eventually, like six yesrs later, customers complained enough that
the filters had to be removed.  when a big customer or two wanted to
get to someone with a /24 in old B space, the filters fell.
business wins.

when v4 runout forces folk to put /28s in frnt of nats, the folk with
shiny shoes will have a little chat with senior leadership, and they'll
cough up the bucks to hold the routes.  history repeats.

like the ethernet mfrs tell us that we need to use 4g, 40g, ... instead
of 10g, 100g, 1tb, ... life adds zeros.

randy

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

> Looks to me that there is still IPv4 space being returned, the
> run-rate on 185/8 is constant, we have approximately 4-5 years to go?

and you believe that there will be zero desirable ipv4 destinations on the
internet by then?  sure does not look like it as far as i can see.

and if a new entrant needs to reach the remaining ipv4 internet, ...?

randy

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