- address-policy-wg - mailman.ripe.net

New on RIPE Labs: IPv4 Allocations - Is Fairness Still the Goal?
by Angela Dall'Ara 03 Mar '22

03 Mar '22

Dear colleagues, An interesting discussion took place last December on whether current policies and procedures for the allocation and transfer of IPv4 resources in the RIPE NCC service region are in line with the original policy intent. To help lend clarity on the issue, I give an overview of the relevant changes that have come into effect since the RIPE NCC started distributing the last /8 we received from IANA. I hope you will find this helpful. https://labs.ripe.net/author/angela_dallara/ipv4-allocations-is-fairness-st… Kind regards, Angela -- Angela Dall'Ara RIPE NCC Policy Officer

1 0

RU goverment IP revoke
by Den 01 Mar '22

01 Mar '22

Hi Jan, Thanks for your time, looks like other's are too busy or already at the basement / under attack.. Here's what I've found: AS8291 The Federal Guard Service of the Russian Federation / Main Division of Informations Resources / kremlin.ru, etc. AS43797 The Federal Guard Service of the Russian Federation AS42121 The Federal Guard Service of the Russian Federation AS48552 OJSC The Russian Armed Forces Broadcasting Company ZVEZDA AS57767 Federal State-owned Enterprise Russian Television and Radio Broadcasting Network AS57352 Federal State Unitary Enterprise Rossiya Segodnya International Information Agency AS57107 Federal State Unitary Enterprise "Russian Satellite Communication Company" AS57767 Federal State-owned Enterprise Russian Television and Radio Broadcasting Network AS59541 Federal State-owned Enterprise "Russian Television and Radio Broadcasting Network" AS44479 Federal State Unitary Enterprise Rossiya Segodnya International Information Agency AS25292 Federal State Unitary Enterprise "The Russian Television and Radio Broadcasting Company" AS211382 Federal State Unitary Enterprise of the Order of the Red Banner of Labour "Russian Broad-casting and AS208075 Federal State Unitary Enterprise of the Order of the Red Banner of Labour "Russian Broad-casting and AS201030 Federal state unitary enterprise "Public corporation for organisation of air traffic in Russian Fede AS198372 Federal State Unitary Enterprise "Television Technical Center "Ostankino" AS197969 Federal State Unitary Enterprise "Morsviazsputnik" AS197553 Federal state unitary enterprise 'State Research Institute of Aviation Systems' AS197150 Federal State Unitary Enterprise of the Order of the Red Banner of Labour "Russian Broad-casting and AS196641 Federal Unitary State Enterprise General Radio Freqency Centre AS57724 DDOS-GUARD THAT HIDES RT.COM and others russian's broadcasting companies .... (This list can be much longer, it's from my quick research) Guys, who read, please help us, please make some unexpected failures, anyway you know what to do. *Let's make our work Now!* Thanks for all of you guys, we all want Internet with freedom and without dictatorship! Love and peace for all of you guys! -- Cheers, Den

4 5

RU goverment IP revoke
by Den 28 Feb '22

28 Feb '22

Hi Taras, Leo, Jordi, Kurt, Saludos, Max, Sergey, Jan, Gert, Thomas, Stary! from recent posts we can see that the problem persists and it can be just ignored, and from the recent post, a very detailed explanation: > The problem is that Russia is under the control of a criminal dictator and a crazy one. He is just looking for a worldwide nuclear conflict, clearly. According to the news, now he just threatened Finland and Sweden. the keyword is "news", i mean fake news, and broadcasting agencies, television and related government structures should be suspended from the whole internet. It's a kind of abuse, but you know if you will send them, they'll just ignore. The ones who can do such things is only our community, community of thinking people that wants freedom in the Internet without such dictatorship resources. Guys I'm asking you to help real thinking russian people to prevent dictator's media posting and broadcasting fake news to the Internet! And here we, our community can help a lot, because we are the core of the Internet, actually we have rights! In case you do not want to officially suspend or freeze their peering/ASNs/routes you know how to create some technical incidents and fix them for a long time.. :)

2 1

Block/Suspend sanctions on address space.
by Alexey Shkittin 26 Feb '22

26 Feb '22

*Block/Suspend sanctions on address space.* Based on events with Russian aggression on Ukrain. Policy Proposal for discussion. Update RIPE NCC policy in according to be able suspend management of internet resource numbers in RIPE NCC database of the countries under Sanctions in EU/US. This is necessary for direct influence on the side subjected to sanctions. This applies in particular to governmental and related organizations. For these purposes, for example, government and related companies of the state subject to sanctions are limited to control and access to Lirportal and Maintainers, and forcefully remove all objects operating under the ASN of these institutions. This will entail the impossibility of the state to carry out activities related to the use of IT technology, the Internet, the spread of propaganda and fakes, including (armies of bots from different IPs, cyber attacks initiated by the state, and much more) Since the RIPE NCC implements the decisions of the RIPE community, it is proposed to introduce a change in the Ripe policy related to the implementation of global and European sanctions. This policy can only be applied to states under sanctions. These states should not be able to obtain and use ASNs and IP addresses for government purposes. Ripe sanctions should not apply to ordinary users, since the total shutdown of all LIRs located inside the state under sanctions will lead to the inevitable transition to an internal network controlled by government services and deprive the population of communication with the outside world and information. *Alexey Shkittin*

6 7

RU goverment IP revoke
by Max Tulyev 26 Feb '22

26 Feb '22

Hello All, let's think about sanctions against Russia. What do you think about revoking all IPs/ASNs used by Russian goverment?

9 9

RU goverment IP revoke
by JORDI PALET MARTINEZ 26 Feb '22

26 Feb '22

The problem is that Russia is under the control of a criminal dictator and a crazy one. He is just looking for a worldwide nuclear conflict, clearly. According to the news, now he just threatened Finland and Sweden. If the rest of the world keeps surrendering to his wishes, as we did many times, many governments, even when he perpetrated criminal actions outside his own territory (for example, poisoning in UK, invasion of Crimea, etc.), he will never stop. The Russian population has "accepted" him; they are somehow responsible. If they really wished hard to take him down, there are 150 million of people in the country to take an action and they had many years to do so. I know is very easy to say, not so easy to act, but I'm not talking about a single person acting. He is precisely knowing that we will think "we can't do this because the poor population". People from Russia has been connected to Internet and they know sufficiently how their dictator is acting inside their country and towards the rest of the world. Situation has not changed across the years, and they haven´t reacted. Is time for a strong action from all the possible sides. We have a new "Bin Laden", which is million times much more powerful and if the rest of the world is not acting, we will suffer it sooner or later. If we think twice, economic sanctions will also be bad for the population, and just dust for the dictator. Those economic sanctions will also be bad for the rest of the world. I agree with them. I disagree with offensive military actions, but at the same time we must find as many possible ways to isolate the country and unless in his craziness he pushes the nuclear buttons first (as an offensive action), sooner or later that will create sufficient internal country reactions to topple him. Unfortunately, I don't think there is any other path forward and it will be ideal that voluntarily, until governments that the decision, carriers and ISPs, filter all their traffic, which also could at least in some %, avoid some of the cyber-attacks that are coming from there, which can target not just Ukraine, but any other country. Hi, On Fri, Feb 25, 2022 at 06:07:32PM +0100, Kurt Kayser wrote: > Internet is the fasted and most efficient way to show what happens and > who is responsible for it. > > Let's all work together that this stay this way. My initial toughts were similar to what was proposed ("let's just cut off ALL Internet to .RU! That will hurt them!") I have reconsidered, and now share the opinion that Kurt voiced - cutting off Internet access will hurt the russian people more, and benefit the spreading of misinformation. So, make sure Information can flow. Gert Doering -- just a concerned user -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

3 3

IPv6 - Geolocation concerns
by Michalak, Damian 01 Feb '22

01 Feb '22

Hi there, This is a follow-up question to the older thread ("IPv6 - Using RIPE acquired prefix in other regions") Situation: I have acquired /32 IPv6 prefix from RIPE NCC. Prefix is registered for country: DE. I'm going to create /48 subnets and advertise them from various locations all around the globe. Question: Do I have to be concerned about geo-location issues? For example someone in US opening Google and getting Google.de? If so - what's the best way to address this? P.S. That's certainly a concern in IPv4 - I do advertise in US a subnet of a bigger supernet (registered in Poland) and Apple.com thinks I'm in Poland. Thanks

4 4

IPv6 - Using RIPE acquired prefix in other regions
by Michalak, Damian 27 Jan '22

27 Jan '22

Hi there, I'm quite confused and would appreciate your help - let's say I acquired /32 IPv6 prefix from RIPE NCC. I work for a company with a global footprint with locations at various regions (including ones covered by APNIC and ARIN). I create a subnet plan that assigns /48 to each location with the company. So each /48 falls into the /32 assigned by RIPE. Now let's take as an example a location in the USA. I have this location connected using Direct Internet Access link from one of the providers. BGP is established. Question: can I advertise the /48 subnet (that falls into the /32 assigned by RIPE) from the location that in theory falls into ARIN regulatory domain? I cannot find an answer on that anywhere, and I'd like to make sure that I don't have to acquire additional prefixes from other RIRs. Thanks

2 2

RIPE 83 Minutes
by Leo Vegoda 06 Jan '22

06 Jan '22

Dear WG, The RIPE NCC has now published draft minutes of our session at RIPE 83. The page also links to recorded content and supporting materials. Please write to this list or inform the co-chairs of any issues or corrections. https://www.ripe.net/participate/ripe/wg/active-wg/ap/minutes/ripe-83-addre… Kind regards, Leo Vegoda for the Address Policy WG co-chairs

1 0

ripe-682 Transfer Policy Problems
by denis walker 05 Jan '22

05 Jan '22

Colleagues The Transfer Policy ripe-682 is so vague you can drive a train through the holes in it. I have some questions that I hope someone can answer before Christmas as I would like to propose an amendment to this policy in the new year. "Any legitimate resource holder is allowed to transfer" What does 'legitimate' mean in this context? It is not defined in this policy document. It is no use referring to a dictionary or even some other policy document. It needs to be defined in this policy. If it has no specific meaning in the context of this policy, then the word should be removed. My understanding of a 'policy document' is that it is self contained and consistent. None of the terms: -RIPE NCC Member -LIR -Resource holder are defined anywhere in the Transfer Policy or ripe-733, IPv4 Allocation... A policy may be dependent on another policy being in place. You cannot transfer a resource unless it has been allocated. You cannot allocate a resource unless there is a RIPE NCC Member and an LIR. But you should not have to backtrack through a whole sequence of documents to find out what a term in this policy means. This policy can only work if people understand 'commonly accepted' definitions of these terms. But that is open to interpretation and mis-understanding. That could make legal enforcement of, for example, restrictions more difficult to apply. [As a side issue I have just quickly read through a whole series of documents and forms on becoming a RIPE NCC Member and getting resources. In every document/form I found: -Legal errors -English grammar errors -Procedural errors -Webpage errors The whole process is a complete mess and needs a serious Legal/Comms review.] I found the definition of a Member in one document but nowhere have I found any definition of LIR. These terms are so fundamental to all these policies, to not define them leaves a massive hole in their meaning and authority. These terms seem to be so interchangeable from one paragraph to the next. In some places the wrong term is used. ripe-733 says allocations are made to LIRs ripe-682 says allocations are transferred to members ripe-682 says transfer restrictions apply to resource holders Then we have this document https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/tra… which talks about 'hodership', another term not defined. Then we have this document https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/tra… that conflicts with the Transfer Policy. It also refers to Members as organisations, again without any actual definition. The above document says: "Exception: For transfers between multiple LIR accounts belonging to the same organisation, also referred to as consolidations, the 24 months restriction will only apply once after the resources were received from the RIPE NCC or from another organisation." This is NOT what the Transfer Policy says. The policy makes no mention anywhere of consolidation. The only definition we have of a transfer in any POLICY is this one line: "Allocated resources may only be transferred to another RIPE NCC member." This does not even make sense. A Member cannot 'hold' a resource. Resources are held by Member LIRs. So if a resource is transferred to a Member with 5 LIRs, which one receives it? Does it matter? Is it whichever LIR the Member writes on the transfer request form? Now a consolidation is not a transfer. In the policy a transfer is defined as moving a resource to 'another Member'. So consolidating a resource by moving it from one LIR to another LIR of the same Member is by policy definition, not a transfer. So consolidation is not subject to Transfer Restrictions because it is not a transfer. So all the shell companies that have been set up this year to hoover up the last /24s can now be merged with their parent company and then all the /24s can be consolidated into one LIR. The other LIRs can then be closed. Nothing in this policy document says a /24 allocation must remain for 24 months with the LIR that it was allocated to. It says it cannot be transferred, but mergers are allowed and consolidation is not a transfer. This is even confirmed in a procedural document ripe-758, Transfer of Internet Number Resources... (which doesn't appear to be policy) "Internet number resources that are subject to transfer restrictions imposed by the RIPE Policy "RIPE Resource Transfer Policies", and that are transferred due to a change in a member's business structure, must either remain registered with the original LIR account or be registered with a new LIR account." So merging a shell company with 20 LIRs, each with a /24, with the parent company with a single LIR, allows those 20 /24s to be registered with the single LIR of the parent company and closure of the 20 LIRs. Also ripe-758 introduces yet another term, parties, without any definition or clarity. This whole transfer process is totally confused with contradictory, inconsistent and poorly written documents and policies. cheers denis co-chair DB-WG

4 5

IPv4 waiting list policy
by Marco Schmidt 20 Dec '21

20 Dec '21

Dear colleagues, In the Address Policy Working Group sessions at RIPE 83, I shared our observations regarding the IPv4 waiting list policy. [1] The intent of this policy was to provide newcomers with a minimal amount of IPv4 space for as long as possible. However, about half of these allocations went to members that received several /24 allocations via multiple LIR accounts. As there was interest in reviewing the policy at the RIPE Meeting, I would like to provide more detail on the provision of IPv4 allocations over the last two years and the current situation with the waiting list. In the last 24 months, we provided 4,178 LIRs with a /24 allocation: - 2,019 allocations (48%) went to members with a single LIR account - 452 allocations (11%) went to members with 2-4 LIR accounts - 298 allocations (7%) went to members with 5-9 LIR accounts and - 1,409 allocations (34%) went to members with 10 or more LIR accounts (up to 33 /24 allocations to a single member) This trend towards allocations to multiple LIR accounts has accelerated in the past six months. Between June and November 2021, only 24% of allocations went to members with a single LIR account, while 54% went to members with 10 or more accounts. We see the same trend with the current waiting list. At the time of writing, we can see 327 requests for a /24 allocation: - 83 (25%) are from members with a single LIR account - 42 (13%) are from members with 2-4 LIRs accounts - 45 (14%) are from members with 5-9 LIR accounts - 157 (48%) are from members with 10 or more LIR accounts Consequently, there is a significantly longer wait time for members with a single LIR account. Looking at the current market prices for IPv4 in comparison to our membership fees, even a wait time of several months is acceptable for organisations that plan to transfer their allocation after the end of the holding period. Conversely, the long wait time will create uncertainty for real newcomers, especially if they can’t rely on IPv6-only networks. I hope the WG finds this information useful for further discussion. If there is consensus to change the current situation, there are several approaches available – including a review of the waiting list policy and changing ‘per LIR’ to something else. Other approaches, such as a different charging scheme or changing the concept of multiple LIRs would need to be approved by the RIPE NCC membership. Kind regards, Marco Schmidt Assistant Manager Registry Services RIPE NCC [1] https://ripe83.ripe.net/archives/video/642/

26 65

IPv4 waiting list policy
by Albanian Hosting SH.P.K. 17 Dec '21

17 Dec '21

Hey Denis Walker, in 2019 until the end of december the last /22 allocation was assigned to the members/Lirs, once the ripe stopped assigning /22, there was not that much interest in 2020 for only a /24 subnet. And no, it was not free! Since in 2021 the price per IP skyrocketed, and ripe announced that they are out of stock, due because of this and due because the price per IP is going to the moon, the LIRs (mostly big boys) with multiple allocations started to apply for more and believe me they are making a good profit from this. For now is 200€/month is the price for /24 subnet to rent out, and it will be higher and higher. Cheers. -- *Sinqerisht / Sincerely,* AlbHost [image: Logo] <https://www.albahost.net/> Albanian Hosting SH.P.K. Besim Beka p.n. 50000 Gjakovë, Kosovë. NIPT/VAT ID: 811442657 T: +386900501502 E: info(a)albahost.net W*: *wWw.AlbaHost.Net <http://www.albahost.net/> [image: Facebook icon] <https://www.facebook.com/albanianhosting> [image: Twitter icon] <https://twitter.com/albahost> [image: Instagram icon] <https://www.instagram.com/albahost_vpn/> [image: Banner] Përmbajtja e këtij emaili është konfidenciale dhe ka për qëllim marrësin e specifikuar vetëm në mesazh. Ndalohet rreptësisht shpërndarja e ndonjë pjese të këtij mesazhi me ndonjë palë të tretë, pa pëlqimin me shkrim të dërguesit. Nëse e keni marrë këtë mesazh gabimisht, ju lutemi përgjigjuni këtij mesazhi dhe ndiqni me fshirjen e tij, në mënyrë që të sigurohemi që një gabim i tillë të mos ndodhë në të ardhmen. The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future.

8 10

Fwd: IPv4 waiting list policy
by Albanian Hosting SH.P.K. 16 Dec '21

16 Dec '21

Hello Gert, appreciate your response, i do believe that you started to care when something is dead now trying to bring to life! On most replies here are only shooting on newcomers/lirs in which no new lir is getting more than a /24, and nobody is talking for those lirs that have multiple resources /16, /17, /20, /21, /22 etc, in which you can clearly see that there is no usage of it by theirself but only leasing/renting them out to those who cannot effort to be LIR and even if they effort it, cannot get more than a /24 allocation. There must be a policy in which it will stop those behaviours of LIRs, if you don't need that much of resource, then return it simple as that, and prevent them from leasing out to people like us. I was working as an IT in one of University in which it has a /16 allocation, and only in use less than a /24, all remaining resource is leased out with monthly fee of course. Of course, if you check every single University in the world has min /15, /16 allocation what for? There are many countries like ours in which IPv6 is nowhere implemented yet, and there are many applications in which is not yet ready for IPv6. So therefore, i hope that this would be considered. Cheers. On Thu, Dec 16, 2021 at 7:46 PM Gert Doering <gert(a)space.net> wrote: > Hi, > > On Tue, Dec 14, 2021 at 03:03:05PM +0100, Albanian Hosting SH.P.K. via > address-policy-wg wrote: > > Very interesting! Good catch. And thank you for the information > provided, i > > personally believe that there is no help as because nobody cares at least > > not the RIPE NCC itself. I do believe that we all are wasting our time > > here, as long as my small company need a /22 allocation and cannot get > it, > > it's worthless. We are renting them from others in order to survive! > > If you have read this thread, you might have noticed that people *do* care. > > It's just not very clear what can be done, at this point in time, which > will have a positive effect. > > There's lots of things that can be done that have negative effects > (like, etra bureaucracy, which increases costs, which then leads to > complaints about, well, bureaucracy) but have very little effect on > the problem statement: networks getting "more than one /24" for the > same entity. > > The problem statement is not as clear cut as it might seem... if a parent > company opens a new subsidiary in every european country, which has their > own network, budget, CEO... shouldn't they be entitled to have a LIR > account and a /24 for each subsidiary? > > > ... and, of course, it's not like we haven't been telling people since > 15+ years that IPv4 is going to run out, and they should use IPv6. > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael > Emmer > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > -- *Sinqerisht / Sincerely,* AlbHost [image: Logo] <https://www.albahost.net/> Albanian Hosting SH.P.K. Besim Beka p.n. 50000 Gjakovë, Kosovë. NIPT/VAT ID: 811442657 T: +386900501502 E: info(a)albahost.net W*: *wWw.AlbaHost.Net <http://www.albahost.net/> [image: Facebook icon] <https://www.facebook.com/albanianhosting> [image: Twitter icon] <https://twitter.com/albahost> [image: Instagram icon] <https://www.instagram.com/albahost_vpn/> [image: Banner] Përmbajtja e këtij emaili është konfidenciale dhe ka për qëllim marrësin e specifikuar vetëm në mesazh. Ndalohet rreptësisht shpërndarja e ndonjë pjese të këtij mesazhi me ndonjë palë të tretë, pa pëlqimin me shkrim të dërguesit. Nëse e keni marrë këtë mesazh gabimisht, ju lutemi përgjigjuni këtij mesazhi dhe ndiqni me fshirjen e tij, në mënyrë që të sigurohemi që një gabim i tillë të mos ndodhë në të ardhmen. The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future. -- *Sinqerisht / Sincerely,* AlbHost [image: Logo] <https://www.albahost.net/> Albanian Hosting SH.P.K. Besim Beka p.n. 50000 Gjakovë, Kosovë. NIPT/VAT ID: 811442657 T: +386900501502 E: info(a)albahost.net W*: *wWw.AlbaHost.Net <http://www.albahost.net/> [image: Facebook icon] <https://www.facebook.com/albanianhosting> [image: Twitter icon] <https://twitter.com/albahost> [image: Instagram icon] <https://www.instagram.com/albahost_vpn/> [image: Banner] Përmbajtja e këtij emaili është konfidenciale dhe ka për qëllim marrësin e specifikuar vetëm në mesazh. Ndalohet rreptësisht shpërndarja e ndonjë pjese të këtij mesazhi me ndonjë palë të tretë, pa pëlqimin me shkrim të dërguesit. Nëse e keni marrë këtë mesazh gabimisht, ju lutemi përgjigjuni këtij mesazhi dhe ndiqni me fshirjen e tij, në mënyrë që të sigurohemi që një gabim i tillë të mos ndodhë në të ardhmen. The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future.

1 0

IPv4 waiting list policy
by Albanian Hosting SH.P.K. 12 Dec '21

12 Dec '21

Hello there, it is interesting to see that everyone is shooting to newcomers/new LIRs and nobody is talking about existing one, it is not the issue to prevent transfer resources, the issue is that almost 70% of members that have multiple /20, /21, /22, /24, are renting the IPs. They took from RIPE and renting out at minimal 150 upto 200€/month for a /24 subnet. The same thing happen to us, as a small company that we cannot get more than a /24 subnet we are forced to rent IPs from those who have multiple LIR accounts and alot of IPs for mentioned price. By implementing the non-transfer resources from newcomers/LIRs you will not solve anything, or maybe a less precentage, but you will not stop big boys with alot of resources to rent them with 200€/month (for now, the price will go up) for a /24 subnet. I do agree with Rick Bakker posts. Kind Regards, Mentor L. -- *Sinqerisht / Sincerely,* AlbHost [image: Logo] <https://www.albahost.net/> Albanian Hosting SH.P.K. Besim Beka p.n. 50000 Gjakovë, Kosovë. NIPT/VAT ID: 811442657 T: +386900501502 E: info(a)albahost.net W*: *wWw.AlbaHost.Net <http://www.albahost.net/> [image: Facebook icon] <https://www.facebook.com/albanianhosting> [image: Twitter icon] <https://twitter.com/albahost> [image: Instagram icon] <https://www.instagram.com/albahost_vpn/> [image: Banner] Përmbajtja e këtij emaili është konfidenciale dhe ka për qëllim marrësin e specifikuar vetëm në mesazh. Ndalohet rreptësisht shpërndarja e ndonjë pjese të këtij mesazhi me ndonjë palë të tretë, pa pëlqimin me shkrim të dërguesit. Nëse e keni marrë këtë mesazh gabimisht, ju lutemi përgjigjuni këtij mesazhi dhe ndiqni me fshirjen e tij, në mënyrë që të sigurohemi që një gabim i tillë të mos ndodhë në të ardhmen. The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future.

1 0

IPv4 waiting list policy
by Diederik de Zee 08 Dec '21

08 Dec '21

2 1

Re: [address-policy-wg] IPv4 waiting list policy
by Rick Bakker 08 Dec '21

08 Dec '21

Dear colleagues, While it is really interesting to see that the waiting list is primarily used as a means of extension for existing LIRs, it would be rather more interesting to look at the current size of the respective LIRs. It makes a lot of sense for a small LIR holding a single /24 to open a second and request a secondary /24. Effectively, holding a /23 worth of IPv4 space is still negligible in comparison to some of our fellow LIRs holding a trifold of that. It seems a countermeasure to restrict every single new /24 allocation in terms of a transfer. It will only prevent new colleagues in order for them to grow and excel in their various new concepts. I would personally strongly advocate restrictions, but only for those who already ‘hold a lot’. It is simply unfair to limit new entrepreneurs in their ventures by throwing monetary bars that hold them back in potential growth. This will only really benefit the bigger colleagues among us, as the new small ‘fish’ are unable to compete because they lack resources to deliver a proper alternative. As such, I would rather propose a maximum amount of /24s (through new memberships) to be requested through the current waiting list policy by a single entity in a given time frame. It is not unrealistic to limit this at a single /24 per e.g. six months. This would result throwing the real ‘hoarders’ under the bus, by not facilitating their hunger for obtaining IPv4 ‘at the cheap’, while still allowing ‘legitimate’ new members to grow by allocating them the resources they need. Also, let’s not forget that while the IPv4 waiting list hands out IPv4 from the RIPE NCC ‘free’ pool, the amount of IPv4 that is recovered is very limited and will probably be even more limited in the foreseeable future. It would make a lot more sense to push at recovering more space, that can than be handed to new colleagues in a more fair, somewhat more restrictive way. Just by looking at some public looking glasses, I can find examples of hobbyist / amateur associations that hold a /16, while it seems not nearly a quarter of that is in active use. While it has been rejected a lot of times before, and another shot at it likely won’t make a difference, the real way to recover IPv4 space, seems to be by putting monetary sanctions on free space. Think of this in terms of changing the way the RIPE NCC does their billing. At current, every single LIR, no matter its size, pays the same contribution towards our association. This policy does NOT push fellow members into returning space they no longer need, or won’t need in the foreseeable future, as holding it does not cost anything. When replacing the current billing scheme into a more flexible billing scheme where each individual IPv4 held can and will be billed, the organisations that do not need the space will return the free space. After all: why pay for resources that you do not need, and won’t need? Of course, for smaller LIRs, this impact won’t be significant. But picture a LIR holding several /16s, of which only a couple of /24 prefixes are in active use? At a small fee of say 10 euro cents per IPv4 address, returning half of a /16, would mean an annual reduction of costs by 6K. Such amount is not that significant, but big enough to push smaller LIRs that hold such an amount of unused space, to return the unused parts. Such a policy could free up a lot of unused space that can then be redistributed to our new colleagues through a more restrictive waiting list mechanism. In this current discussion, some of our fellow colleagues have a tendency to ignore identifying a problem, because they believe IPv4 will ‘die’ on a short term. Let’s face it: at current, a proper hosting service cannot be delivered without IPv4. Of course, there is a steady growth to be identified in global IPv6 usage, this does not mean we can simply have new colleagues ‘wait’ another ten years or so before their IPv6-only services can be seen as mature enough for production use. To wrap up my argument: the sole way of resolving this matter is by having the older LIRs be lenient enough to help recover space by returning it, and redistributing it in a fair manner. It is often said that. The current ‘guild’ of network engineers like to see the next generation grow up, and show interest in their very interesting field. I, myself, at the young age of 21, identify myself as such. But without any leniency from their end to help give everyone a fair chance at starting their own online ventures, by means of allocating at least the most essential resources for them to get going, this will only get harder and harder in the years to come. Yes, my stance will generate a lot of resistance, I am sure, by exactly the group I mentioned that will in this matter show a lack of lenience. But please, all, let’s take a stance that is serious and will help us all along in times of the ‘real-real-real’ scarce of IPv4 in our service region. Regards, Rick Bakker

1 0

Review of IPv6 Policy Goals
by Leo Vegoda 29 Nov '21

29 Nov '21

Dear Address Policy WG, This is the promised message to begin a review of the IPv6 Policy Goals, following the introduction of the subject during our session at RIPE 83. Several people have already spoken up and stated their intent to participate. We’d like to invite everyone interested to respond to the questions below, so we can gauge the WG’s interest in this subject and plan the next steps on that basis. For those who were unable to attend the session, the slides can be found here: https://ripe83.ripe.net/wp-content/uploads/presentations/37-RIPE-83-APWG-IP… And the video recording is here: https://ripe83.ripe.net/archives/video/644 You can find the goals in full in our current IPv6 policy document: https://www.ripe.net/publications/docs/ripe-738#3 There are two main motivations for this discussion. Firstly, the world around us has changed over the 20 years since the goals were integrated into the policy. Secondly, the RIPE NCC is guided by these goals when it implements policy. If there is some degree of executive discretion on how to implement a policy then the RIPE NCC's people will do their best to implement a policy in a way that achieves the overall policy goals. This means that any changes to the IPv6 policy goals could have two impacts: 1) The RIPE NCC might adjust its implementation of one or more existing policies so that those implementations work towards the updated goals. 2) People in the RIPE community might identify a need for policy changes and initiate a policy discussion. The specific questions we'd like to ask the community to discuss are: A) Are all of the goals still relevant? B) Should the priority or wording of goals change? C) Does our changing world require new goals? Responses in support of keeping the goals unchanged are just as welcome as responses indicating that a change is necessary. We look forward to reading your thoughts. Kind regards, Leo Vegoda for the Address Policy WG co-chairs

1 0

Re: [address-policy-wg] IPv6 Stockpiling
by Adrian Bolster 29 Nov '21

29 Nov '21

Good day to you! All important information you asked for you can find in the document via the link below. 1)dancetvshow.com/laboriosamporro/quiadolorum-4312207 2)meralawfirm.com/inventoreodit/sedeos-4312207 The stats on adoption are far more interesting when you look at them by country: https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-ad… That 34% is concentrated in a quite small number of countries -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com/ https://blacknight.blog/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Personal blog: https://michele.blog/ Some thoughts: https://ceo.hosting/ ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845 From: address-policy-wg <address-policy-wg-bounces(a)ripe.net> on behalf of Jetten Raymond <raymond.jetten(a)elisa.fi> Date: Sunday, 31 October 2021 at 17:31 To: Jake Brander <jake(a)brandergroup.net>, Gert Doering <gert(a)space.net>, Sander Steffann <sander(a)steffann.nl> Cc: RIPE Address Policy Working Group <address-policy-wg(a)ripe.net> Subject: Re: [address-policy-wg] IPv6 Stockpiling [EXTERNAL EMAIL] Please use caution when opening attachments from unrecognised sources. Hi Jake, Thanks for your comment. According to https://www.google.com/intl/en/ipv6/statistics.html about 34 % of the internet users that access google use IPv6, and i fully agree that its not enough. In case you have some ideas on how to improve this miserable amount i welcome you to the IPv6 working group mailing list and share your thoughts.. Best Regards, Ray One of the IPv6 wg co chairs https://www.ripe.net/participate/ripe/wg/active-wg/ipv6 Hanki Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: address-policy-wg <address-policy-wg-bounces(a)ripe.net> on behalf of Jake Brander <jake(a)brandergroup.net> Sent: Friday, October 29, 2021 8:59:41 PM To: Gert Doering <gert(a)space.net>; Sander Steffann <sander(a)steffann.nl> Cc: RIPE Address Policy Working Group <address-policy-wg(a)ripe.net> Subject: Re: [address-policy-wg] IPv6 Stockpiling It seems like stock piling IPv6 is similar that what occurred with IPv4 a long time ago. The only difference is nodbody is using IPv6 and there is an abundance of it available.. How do we get people to actually use it? All the best, Jake Brander President | Brander Group Inc. O: (702) 560-5616 x700 | M: (310) 595-6266 jake(a)brandergroup.net | www.brandergroup.net<http://www.brandergroup.net> <http://www.brandergroup.net> Featured in Inc. Magazine & Ranked #6 on Inc. 5000 ? Read More <https://brandergroup.net/2021/08/brander-group-ranked-6-on-inc-5000-in-2021/> On 10/29/21, 8:04 AM, "address-policy-wg on behalf of Gert Doering" <address-policy-wg-bounces(a)ripe.net on behalf of gert(a)space.net> wrote: Hi, On Fri, Oct 29, 2021 at 04:38:46PM +0200, Sander Steffann wrote: > If this is indeed the reason I see no problem with it. That's just operational reality. > > If there is some misunderstanding causing LIRs to accumulate many IPv6 allocations then we can look at better education. > And if there is some malign reason for it, then we can look at changing the policy. > > I think we need to understand the symptoms better to be able work on the cure :) This! Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 For Internal Use Only

1 1

do we need a policy for avoiding "multiple unjustified LIRs"?
by JORDI PALET MARTINEZ 24 Nov '21

24 Nov '21

Hi all, After looking at the video from Marco, today presentation/discussion and the recent discussions on this, as I just mention, should we work in a policy proposal to amend the internal procedure so the justification for additional LIRs is stronger? I understand many cases for the need of an additional LIR, but doing valid for *any artificial case* is not good. Any though on that? Possible ideas about how we define the border line? As usual, I'm happy to work on this myself, or together with other folks. Regards, Jordi @jordipalet ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

4 5

Suggestion to replace IPv4 waiting list with auctions
by Wolfgang Zenker 24 Nov '21

24 Nov '21

Greetings, in todays WG session Marco Schmidt pointed out that more than half of the /24s allocated from the waiting list pool go to members with multiple LIRs. The number of newly created LIRs eligible for a /24 has increased a lot in recent months, to the point where requests can no longer be filled from the available pool but new LIRs have to wait for blocks coming out of quarantine. This change appears to be due to market value for IPv4 blocks being now significantly larger than the cost for creating a new LIR and maintaining it for the two year holding period. The result of this is that newcomers have no easy access to a first IPv4 block but have to wait in line together with multi-LIR address hoarders, defeating the purpose of the waiting list policy. I suggest to replace the waiting list with the following system: - /24s becoming available are put to an auction. - every interested member organisation (NOT: LIR) can make a bid of an amount that is not visible to the other bidders. - highest bid wins. Expected result would be less requests from address hoarders because they could get address blocks for a similar price on the open market without the additional overhead of creating a new member. Newcomers on the other hand would have to become members to be able to hold addresses in the first place, and can use the auction to get access to a properly quarantined address block to start their business. Regards, Wolfgang Zenker -- punkt.de GmbH Tel. +49 721 9109-500 Fax: -100 .infrastructure info(a)punkt.de https://infrastructure.punkt.de/ Kaiserallee 13a CEO: Jürgen Egeling, Daniel Lienert, Fabian Stein D-76133 Karlsruhe AG Mannheim HRB 108285

8 13

IPv6 Stockpiling
by James Kennedy 24 Nov '21

24 Nov '21

[changed mail client alias\author to my name, apologies for duplication] Hi, Re: 'who does IPv6 hoarding really hurt' or 'what's the danger', we should learn from some very harsh real-life lessons that happened with IPv4 stockpiling. - when IPv4 was plentiful, a number of RIPE members we able to hoard vast volumes of IPv4 and distribute large IPv4 network prefixes (e.g. full /18s) to their customers but provide little to no technical services (became de facto local RIRs) - this was attractive to their customers at the time - often network operators - because the RIPE members would lease the address space for a much lower price than a RIPE NCC membership fee - as their customers became increasingly dependant on those IPv4 network prefixes over time to run their operations, the RIPE members abused their power and raised the lease costs to absolute extortionate and unaffordable amounts - often to sell the parent allocation on the IPv4 market This is in addition to conflicting with RIPE IPv6 goals and policy, and reducing the RIPE NCC's ability to check and verify that the address space is being used in line with RIPE IPv6 goals and policy. Do we really want to sleepwalk into a similar situation with IPv6? If not, how can we proactively safeguard IPv6 from such abuse while ensuring easy access to IPv6 for real deployments? Change IPv6 transfer policy, and/or lower the RIPE NCC membership fee (e.g. a cheaper IPv6-only membership category)? Regards, James apwg co-chair

2 1

Assignments from a /24 allocation
by denis walker 24 Nov '21

24 Nov '21

Colleagues The issue came up again today at the AP-WG session at RIPE-83 about making assignments from a /24 allocation. People are forced to create two 'artificial' /25 assignments. Again this is used as one argument against having to register assignments in the RIPE Database. Regardless of the bigger picture about registering assignments, there is a simple solution to the /24 allocation issue. Make the "status:" attribute multiple. Then this /24 INETNUM object can have: status: ALLOCATED PA status: ASSIGNED PA Business rules can restrict the use of multiple status to very specific use cases. Maybe only allow a second status of 'ASSIGNED PA' in an object with status 'ALLOCATED PA'. The normal rules then apply to an assignment, so there can be no more specifics. Then any allocation of any size can be assigned in its entirety without having to create more specific pseudo assignment objects. Business rules could also allow this option for 'SUB-ALLOCATED PA'. cheers denis co-chair DB-WG

2 1

Excellent Presnetations & Videos, how can I help?
by Karla Wagner 23 Nov '21

23 Nov '21

Good Morning! The material presented hung together well, and the speakers asked excellent questions. Thank you for that !! Having a keen interest (and a course or two) in public policy, I'd be interested in helping out. Please let me know. (The speaker indicated that help was needed, and to refer to the mailing lists.) Met vriendelijke groet, Karla Verzonden door ProtonMail Secure Email.

2 1

IPv6 Stockpiling
by _ _ 23 Nov '21

23 Nov '21

Hi, Re: 'who does IPv6 hoarding really hurt' or 'what's the danger', we should learn from some very harsh real-life lessons that happened with IPv4 stockpiling. - when IPv4 was plentiful, a number of RIPE members we able to hoard vast volumes of IPv4 and distribute large IPv4 network prefixes (e.g. full /18s) to their customers but provide little to no technical services (became de facto local RIRs) - this was attractive to their customers at the time - often network operators - because the RIPE members would lease the address space for a much lower price than a RIPE NCC membership fee - as their customers became increasingly dependant on those IPv4 network prefixes over time to run their operations, the RIPE members abused their power and raised the lease costs to absolute extortionate and unaffordable amounts - often to sell the parent allocation on the IPv4 market This is in addition to conflicting with RIPE IPv6 goals and policy, and reducing the RIPE NCC's ability to check and verify that the address space is being used in line with RIPE IPv6 goals and policy. Do we really want to sleepwalk into a similar situation with IPv6? If not, how can we proactively safeguard IPv6 from such abuse while ensuring easy access to IPv6 for real deployments? Change IPv6 transfer policy, and/or lower the RIPE NCC membership fee (e.g. a cheaper IPv6-only membership category)? Regards, James apwg co-chair

1 0

1st Draft Agenda for Address Policy WG at RIPE 83
by Leo Vegoda 21 Nov '21

21 Nov '21

Dear Address Policy WG, Here is the first draft agenda for RIPE 83's Address Policy WG. We want to give as much time as possible to discussion. For this reason, we are continuing with the concept of pre-publishing videos and slides for report items on the agenda. This way, people can review the presentations at their leisure, allowing us to dedicate more time to answering questions and discussing issues with each other. You will be able to watch pre-recorded presentations and review slides from Monday, 15 November. They will be available on https://ripe83.ripe.net and we will send a note linking to the relevant page. Kind regards, Leo Vegoda for the Address Policy WG co-Chairs A. Administrative Matters (5 mins) Chairs Welcome, thanking the scribe, approving the minutes, etc. B. ASO AC Report Summary and Questions (10 mins) This will be pre-recorded and published a week ahead. A 2 slide recap will be presented live before questions are taken. James Kennedy / Nurani Nimpuno / Hervé Clement C. NRO NC/ASO AC Candidate Introductions (10 mins) This will be pre-recorded and published a week ahead. A 2 slide recap will be presented live before questions are taken. Ulka Athale, Sr. Communications Officer, RIPE NCC D. Q&A on Current Policy Topics (15 mins) This will be pre-recorded and published a week ahead. A 2 slide recap will be presented live before questions are taken. Angela Dall'Ara, Policy Officer, RIPE NCC E. Q&A on Feedback from the RIPE NCC Registry Services (15 mins) This will be pre-recorded and published a week ahead. A 2 slide recap will be presented live before questions are taken. Marco Schmidt, Registry Services, RIPE NCC F. RIPE Database Requirements TF (10 mins) This will be pre-recorded and published a week ahead. A 2 slide recap will be presented live before questions are taken. James Kennedy G. Break (5 mins) H. Review of RIPE IPv6 Policy Goals (20 mins)

1 2