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

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