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

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