Re: [address-policy-wg] 2017-03, New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)
Hi, Le 22/09/2017 à 08:47, address-policy-wg-request@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/
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
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 ;)
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
Hi, On Sat, 23 Sep 2017, Nick Hilliard wrote:
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.
Or in any other part of the world...
Many humans will only react after a crisis hits, even if the cost of that is higher overall.
Exactly! Cheers, Carlos
Nick
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
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
Hi,
Op 24 sep. 2017, om 04:55 heeft Randy Bush <randy@psg.com> het volgende geschreven:
They are beyond help
not at all. the vendors are more than happy to sell them CGNs, and other NATs of many flavors.
Sorry, I should have specified "from a IPv4 allocation policy point of view" :) Cheers, Sander
They are beyond help
not at all. the vendors are more than happy to sell them CGNs, and other NATs of many flavors.
Sorry, I should have specified "from a IPv4 allocation policy point of view" :)
sorry. but having spent blood and tears on ipv6 deployment for over 20 years, watching ipv6 zealots create a massive NAT market really really hurts. randy
Hi,
Op 24 sep. 2017, om 20:42 heeft Randy Bush <randy@psg.com> het volgende geschreven:
They are beyond help
not at all. the vendors are more than happy to sell them CGNs, and other NATs of many flavors.
Sorry, I should have specified "from a IPv4 allocation policy point of view" :)
sorry. but having spent blood and tears on ipv6 deployment for over 20 years, watching ipv6 zealots create a massive NAT market really really hurts.
Indeed :( Sander
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 <address-policy-wg-bounces@ripe.net>) id 1dvx51-000885-77 for randy@ran.psg.com; Sun, 24 Sep 2017 02:55:39 +0000 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 <address-policy-wg-bounces@ripe.net>) id 1dvx50-000K7L-8w for randy@psg.com; Sun, 24 Sep 2017 02:55:38 +0000 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 <address-policy-wg-bounces@ripe.net>) 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 <address-policy-wg-bounces@ripe.net>) 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 <address-policy-wg-bounces@ripe.net>) 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 <randy@psg.com>) id 1dvx4p-0002yI-Oa for address-policy-wg@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 <randy@psg.com>) 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 <randy@psg.com>) id 1dvx4l-00087z-Nh; Sun, 24 Sep 2017 02:55:24 +0000 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
On 24/09/2017 00:38, Sander Steffann wrote:
...or change the /22 to /24 and keep giving newcomers a tiny bit of addresses for a while longer (what is currently being proposed).
Hey, A quick math what a /24 can give you if you use if for translation/transition purposes only (NAT64 or A+P like MAP-E/T) If you connect to your upstream with *their* IP addresses and not break your /24 into smaller bits and connect your NAT64 or A+P PRR box directly to that BGP router, use first usable address as a gateway, second address as an interface address for your translation/transition box, then you are left with 252 usable addresses for your purpose. That means 65.535 ports per address, giving you 16.514.820 usable ports. Usually sane people predicts between 700 and 1000 ports per user, and that gives you between 16.514 and 23.592 possible users that you can serve at the same time and connect them to legacy IPv4 world. Now everyone will have to figure out if that's enough or not. :) Cheers, Jan
On 26/09/2017 10:26, Jan Zorz - Go6 wrote:
If you connect to your upstream with *their* IP addresses and not break your /24 into smaller bits and connect your NAT64 or A+P PRR box directly to that BGP router, use first usable address as a gateway, second address as an interface address for your translation/transition box, then you are left with 252 usable addresses for your purpose. That means 65.535 ports per address, giving you 16.514.820 usable ports. Usually sane people predicts between 700 and 1000 ports per user, and that gives you between 16.514 and 23.592 possible users that you can serve at the same time and connect them to legacy IPv4 world.
Now everyone will have to figure out if that's enough or not. :)
Forgot to add (thnx Raymond for reminding me of this issue)... While the above numbers may seem technically feasible, the hidden (or not so hidden) forces may want us to go different direction. Apparently there is a Belgium case: https://www.intgovforum.org/multilingual/content/igf-2017-ws-214-how-can-we-... "The emphasis will be put on the Belgium case where the telecom regulator entered in a voluntary agreement with the 4 biggest ISPs in 2012 for them to limit the number of end-users behind each IPv4 addresses for security purposes (to help to identify end-users when served with a legal order in the framework of a criminal investigation). This led to the unintended positive consequence that major Belgium-based ISPs have made strategic business decision to transition quickly to IPv6. As a result, today Belgium has the highest IPv6 adoption rate in the world." I heard (and please correct me if I'm wrong) that in order to have a success in this legal investigations, there should not be more than 4 to 6 users behind each IP address. If this is really the case, then both /22 and /24 are more or less useless for any transition/translation technique if regulation will ever require this ratio as a requirement. :( It's a deep swamp and we created it as an industry with not keeping up properly and deploying IPv6... My question here is: Now what? Cheers, Jan
Hi Everyone, So to conclude* the whole thing, although we have not technically run out, we practically already have, and as you probably know by now, I still see no point in making another policy on this and still oppose this proposal. A /22 is not even enough, let alone a /24 to yet connect to the "dark ages of the IPv4 internet", not now and unfortunately not in the future either... * means I will not again explain my opinion after this on the same subject, it will remain unchanged. Rgds, Ray -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces@ripe.net] On Behalf Of Jan Zorz - Go6 Sent: 26. syyskuuta 2017 13:03 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) On 26/09/2017 10:26, Jan Zorz - Go6 wrote:
If you connect to your upstream with *their* IP addresses and not break your /24 into smaller bits and connect your NAT64 or A+P PRR box directly to that BGP router, use first usable address as a gateway, second address as an interface address for your translation/transition box, then you are left with 252 usable addresses for your purpose. That means 65.535 ports per address, giving you 16.514.820 usable ports. Usually sane people predicts between 700 and 1000 ports per user, and that gives you between 16.514 and 23.592 possible users that you can serve at the same time and connect them to legacy IPv4 world.
Now everyone will have to figure out if that's enough or not. :)
Forgot to add (thnx Raymond for reminding me of this issue)... While the above numbers may seem technically feasible, the hidden (or not so hidden) forces may want us to go different direction. Apparently there is a Belgium case: https://www.intgovforum.org/multilingual/content/igf-2017-ws-214-how-can-we-... "The emphasis will be put on the Belgium case where the telecom regulator entered in a voluntary agreement with the 4 biggest ISPs in 2012 for them to limit the number of end-users behind each IPv4 addresses for security purposes (to help to identify end-users when served with a legal order in the framework of a criminal investigation). This led to the unintended positive consequence that major Belgium-based ISPs have made strategic business decision to transition quickly to IPv6. As a result, today Belgium has the highest IPv6 adoption rate in the world." I heard (and please correct me if I'm wrong) that in order to have a success in this legal investigations, there should not be more than 4 to 6 users behind each IP address. If this is really the case, then both /22 and /24 are more or less useless for any transition/translation technique if regulation will ever require this ratio as a requirement. :( It's a deep swamp and we created it as an industry with not keeping up properly and deploying IPv6... My question here is: Now what? Cheers, Jan
Now everyone will have to figure out if that's enough or not. :)
That is clearly not enough... you are asking the obvious here Jan... ;-) Erik -----Oorspronkelijk bericht----- Van: address-policy-wg [mailto:address-policy-wg-bounces@ripe.net] Namens Jan Zorz - Go6 Verzonden: dinsdag 26 september 2017 10:27 Aan: address-policy-wg@ripe.net Onderwerp: Re: [address-policy-wg] 2017-03, New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) On 24/09/2017 00:38, Sander Steffann wrote:
...or change the /22 to /24 and keep giving newcomers a tiny bit of addresses for a while longer (what is currently being proposed).
Hey, A quick math what a /24 can give you if you use if for translation/transition purposes only (NAT64 or A+P like MAP-E/T) If you connect to your upstream with *their* IP addresses and not break your /24 into smaller bits and connect your NAT64 or A+P PRR box directly to that BGP router, use first usable address as a gateway, second address as an interface address for your translation/transition box, then you are left with 252 usable addresses for your purpose. That means 65.535 ports per address, giving you 16.514.820 usable ports. Usually sane people predicts between 700 and 1000 ports per user, and that gives you between 16.514 and 23.592 possible users that you can serve at the same time and connect them to legacy IPv4 world. Now everyone will have to figure out if that's enough or not. :) Cheers, Jan
On 26/09/2017 17:56, Erik Bais wrote:
Now everyone will have to figure out if that's enough or not. :)
That is clearly not enough... you are asking the obvious here Jan... ;-)
Well, yes and no. We are talking about new entrants here, companies that are fresh new on the market and usually this folx does not build a huuuge network from the very start. If we forget the regulatory restriction possibility in the future, a local residential network of 10k to 20k users is still not too bad for a starter and maybe that might even encourage the increased competition to big-old-boys that will not be able to get more IPv4 resources at all ;) Cheers, Jan
Erik
-----Oorspronkelijk bericht----- Van: address-policy-wg [mailto:address-policy-wg-bounces@ripe.net] Namens Jan Zorz - Go6 Verzonden: dinsdag 26 september 2017 10:27 Aan: address-policy-wg@ripe.net Onderwerp: Re: [address-policy-wg] 2017-03, New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)
On 24/09/2017 00:38, Sander Steffann wrote:
...or change the /22 to /24 and keep giving newcomers a tiny bit of addresses for a while longer (what is currently being proposed).
Hey,
A quick math what a /24 can give you if you use if for translation/transition purposes only (NAT64 or A+P like MAP-E/T)
If you connect to your upstream with *their* IP addresses and not break your /24 into smaller bits and connect your NAT64 or A+P PRR box directly to that BGP router, use first usable address as a gateway, second address as an interface address for your translation/transition box, then you are left with 252 usable addresses for your purpose. That means 65.535 ports per address, giving you 16.514.820 usable ports. Usually sane people predicts between 700 and 1000 ports per user, and that gives you between 16.514 and 23.592 possible users that you can serve at the same time and connect them to legacy IPv4 world.
Now everyone will have to figure out if that's enough or not. :)
Cheers, Jan
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 (do you, if so, why?). Get this aligned with ARIN and the other RIRs, it should be quite possible to get a bunch of /somethings routed at /28 level. But 2017-03 simply raises the cost per /24, without enforcing v6 deployment in any way. It therefore shouldn't pass. Regards, -kai
[ 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
Hi, am 24.09.2017 um 04:58 schrieb Randy Bush:
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.
It's quote common that you need to hand in a kind-of detailed network plan for larger deployments. As part of a revised last /8 policy, a detailed plan for using the requested (not: granted because you're a new LIR) v4 space for transition services can be requested, including evidence for it's deployment within 12 weeks. Yes, "evidence" can be faked. Does faking information currently serves as a breach of contractual obligations by the LIR, opening LIR termination? If not, there's some homework to do. Handing out, say, /28 instead of /24 would spoil this space for any trading. Yes, the route: needs to be on /24 level, but by having a route: entry of the /24 on AS3333 (or, maybe better, some designated "last /8 control ASN") means no other route: entry can be made without active involvement of RIPE NCC. This can be tracked, and the routing AS changes limited to 1 within 24 months. Usage beyond the assigned /28 boundary could be checked as well (RIPE ATLAS or a bunch of AWS instances, fired up randomly). I don't say it's easy. I don't say I like the idea. But I think it's doable and that an upcoming strict "v4 for v6 deployments only" policy is enforcable. The argument pro 2017-03 is "we need to conserve v4 space for those that come late to the show (in 3 to x0 years) and need to connect to github.com, amazon.com or other dinosaurs still on v4-only via transition techniques". Well, anything except an all-in to me is just for raising the per-/24 market price. Unless we poison the upcoming assignments – (strictly?) no transfer, no generic use (yes, this is difficult to "measure and enforce"; nonetheless, a legal phrase of the intended use should be possible and added), assignment way below routing threshold, strong control by RIPE NCC –, those *will* end up in the "v4 after market". In essence, RIPE NCC would "lease" the v4 addresses to these LIRs, not anymore "assign" them. Radical? Maybe. Necessary? To conserve as much v4 space for "anyone coming late", I think so. Regards, -kai
Hi, you still pay only *membership* fee. It's not a per-IP cost, even if it can look like that. Old resource holders pays similar fee independently from number of IP addresses they hold. One of goals is *conservation*, and initial assignment of /24 helps with that - and not each new LIR really needs /22. There're lot of organisationss having single /24 (old PI allocations) from the past and they're still happy with that. These were allocated to end users, are routed and also nobody concerned about routing table size. Since posibility of PI alocations was ceased, new organisations have to become "full LIR" - and then you receive /22, automatically - even you don't need it. We're simply wasting limited addres space here - just because something "simplified" and "automated". Alocating /24 to new LIRs with keeping possibility to earn up to /22 (in case of documented need) is solution in my eyes. Old policies worked perfectly with such system for years - without problems, RIPE NCC has deep experience with that. Administrative overhead will be minimal, as RIPE NCC is also running assisted registry checks even for quite new LIRs (so first iteration of ARC can be done during new request). With regards, Daniel On 09/24/2017 04:38 AM, Kai 'wusel' Siering wrote:
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 (do you, if so, why?). Get this aligned with ARIN and the other RIRs, it should be quite possible to get a bunch of /somethings routed at /28 level.
But 2017-03 simply raises the cost per /24, without enforcing v6 deployment in any way. It therefore shouldn't pass.
Hi Daniel,
you still pay only *membership* fee. It's not a per-IP cost, even if it can look like that. Old resource holders pays similar fee independently from number of IP addresses they hold.
RIPE NCC members can change this charging scheme, right? It was not like this always...
One of goals is *conservation*, and initial assignment of /24 helps with that - and not each new LIR really needs /22. There're lot of organisationss having single /24 (old PI allocations) from the past and they're still happy with that. These were allocated to end users, are routed and also nobody concerned about routing table size. Since posibility of PI alocations was ceased, new organisations have to become "full LIR" - and then you receive /22, automatically - even you don't need it. We're simply wasting limited addres space here - just because something "simplified" and "automated".
An org will not be limited to /24 even with this proposal; they can open additional LIRs to get more. Or register a new business if RIPE NCC bans multi LIR again. It is not easy to say that we are wasting limited address space by allocating /22, the ones need less than an /22 can transfer their free blocks to others who are in need (even new entrants) after two years or lease them immediately. Maybe there are some LIRs don’t fully utilize their /22 as soon as they receive the allocation, but what about the ones got their allocations before last /8 policy, are they all fully used? The actual wasting was done somewhere else years ago, and nobody cares about that now. Regards, Arash
On Mon, 25 Sep 2017, Arash Naderpour wrote:
Hi Daniel,
Hi,
you still pay only *membership* fee. It's not a per-IP cost, even if it can look like that. Old resource holders pays similar fee independently from number of IP addresses they hold.
RIPE NCC members can change this charging scheme, right? It was not like this always...
You are correct: RIPE NCC members. This group is not a perfect match with the community that discusses and builds up policies :-)
One of goals is *conservation*, and initial assignment of /24 helps with that - and not each new LIR really needs /22. There're lot of organisationss having single /24 (old PI allocations) from the past and they're still happy with that. These were allocated to end users, are routed and also nobody concerned about routing table size. Since posibility of PI alocations was ceased, new organisations have to become "full LIR" - and then you receive /22, automatically - even you don't need it. We're simply wasting limited addres space here - just because something "simplified" and "automated".
An org will not be limited to /24 even with this proposal; they can open additional LIRs to get more.
Yes, 2017-03 v1.0 doesn't try to limit that -- if i understood correctly, some people disagree, and think it should.
Or register a new business if RIPE NCC bans multi LIR again.
I guess only the RIPE NCC GA can do that, not RIPE NCC itself.
It is not easy to say that we are wasting limited address space by allocating /22, the ones need less than an /22 can transfer their free blocks to others who are in need (even new entrants)
in need, or not (if they are only trying to stockpile for later...)
after two years or lease them immediately.
Yes... that's current policy, and 2017-03 doesn't touch that.
Maybe there are some LIRs don?t fully utilize their /22 as soon as they receive the allocation, but what about the ones got their allocations before last /8 policy, are they all fully used?
Of course not.
The actual wasting was done somewhere else years ago, and nobody cares about that now.
There is also the issue with "refurbished" address space... apart from the issue that IPv4 address space now has value, so creating a new rule/policy to "extract" it frow its current owners is quite inimaginable... :-) Regards, Carlos Friaças
Regards,
Arash
Moin, am 24.09.2017 um 09:31 schrieb Daniel Suchy:
Hi,
you still pay only *membership* fee. It's not a per-IP cost, even if it can look like that. Old resource holders pays similar fee independently from number of IP addresses they hold.
Please don't get me started on that ... For the time being, assume I runa business and am a LIR already, and a customer who needs 2 /24 for his more-than-awesome service. Will I direct himto competitors that got /16s in the past, or will I opt for another LIR undercurrect policy, calculate that cost and present him with that bill? If all costs (another company, another LIR, etc.) are covered, why would I reject the deal?
One of goals is *conservation*, and initial assignment of /24 helps with that - and not each new LIR really needs /22. There're lot of organisationss having single /24 (old PI allocations) from the past and they're still happy with that. These were allocated to end users, are routed and also nobody concerned about routing table size.
Oh, they did, back then. That's the whole PA vs. PI thing[1], starting somewhere around 194/8or back, in the early 1990s. The idea was to assign huge amounts of address space to an LIR in the expectation it would be routed coherently. Didn't work in 194/8 due to lack of contractual clearance, IIRC 195/8 was the first "safe to filter" prefix? PI space back then was supplied from another netblock (193/8?), so filtering could be applied easily. But sometime later, a generic /24 filter was applied, and that's where we are today, AFAIK.
Since posibility of PI alocations was ceased, new organisations have to become "full LIR" - and then you receive /22, automatically - even you don't need it. We're simply wasting limited addres space here - just because something "simplified" and "automated".
No.A LIR is supposed to hand out addresses to customers based on customer needs (and contractual obligations to RIPE NCC). Shelling out a once-in- your-lifetime /22 prefix just makes sense, if this is an "old-school" LIR. It would typically use a /24 (routing threshold) for itself (www, mx), and seek for customers for the remainding 3 /24. Even if the company's legal entity has no use for v4, v4 address space does have a finacial value these days, so failure to secure that could be a punishable offence.
Alocating /24 to new LIRs with keeping possibility to earn up to /22 (in case of documented need) is solution in my eyes.
As stated elsewhere:anyone will be able to present "documented need" for the /22 ... so this is a moot point. Regards, -kai [1] https://www.ripe.net/publications/docs/ripe-509#----pa-vs--pi-address-space
Hi, On Sat, Sep 23, 2017 at 08:54:01PM +0100, Willy MANGA wrote:
Le 22/09/2017 à 08:47, address-policy-wg-request@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?
The problem is not "the new people" - the problem is "all the other people". What good is having an all-ipv6-network when your users will not be able to shop at, say, www.amazon.de, because that content site is IPv4-only? So you need to have some sort of IPv6-to-IPv4 translator device - and that one needs a few IPv4 adresses. And vice versa, if you host content, you'll need to be able to serve your content to those ISPs like Telefonica that have "no plans to implement IPv6, we can do this all with Carrier Grade NAT44!" [they did a press release to that extent, a few years ago...] - so, a few IPv4 addresses to tack on your load balancers, so they can server IPv6-only content to IPv4-only users... This is the real dilemma here: new entrants on the market feel the pain of old entrants not moving forward. Of course for the old entrants, this is a highly convenient way to keep their costs down, and everyone else's costs high ("externalize", as it has been said before) Gert Doering -- concerned Internet user -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
participants (13)
-
Arash Naderpour -
Carlos Friaças -
Daniel Suchy -
Erik Bais -
Gert Doering -
Jan Zorz - Go6 -
Jetten Raymond -
Kai 'wusel' Siering -
Nick Hilliard -
Randy Bush -
Sander Steffann -
Willy MANGA -
Willy MANGA