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

Personal data in the RIPE Database
by ripedenis＠yahoo.co.uk 04 Mar '19

04 Mar '19

Colleagues I have just sent a message to the Database Working Group about personal data in the RIPE Database and the next step. As this impacts slightly on address policy, which explicitly refers to contact data, and it may involve member services to manage any cleanup of data, I would appreciate input from the members of these two working groups. Perhaps you can check the message on the DB-WG list and respond with your thoughts on that list. cheersdenisco-chair DB-WG

1 0

IPv6 PI justification requirements
by Cynthia Revström 27 Feb '19

27 Feb '19

Hello ap-wg, I am in the process of requesting 3x /48 of IPv6 PI for a customer, and what confuses me is that the NCC requires way more justification for 3x /48 of PI than for 2x /29 of PA. I do think that saying something like net1 will be used in the Netherlands, net2 in London, and net3 in New York should be enough. I mean after all, any LIR can get 512K /48s and unlike ASNs, PI space does have a small fee attached with it. I can't think of a good reason why this is the case. Once again to make it clear, if you are a member it is easier to get 1 million /48s than it is for a non member to get 3 /48s. - Cynthia

9 14

2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)
by Marco Schmidt 23 Feb '19

23 Feb '19

Dear colleagues, A new RIPE Policy proposal, 2019-02, "Reducing IPv4 Allocations to a /24" is now available for discussion. This proposal aims to reduce the IPv4 allocation size to a /24 once the RIPE NCC is unable to allocate contiguous /22 ranges. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-02 As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal. We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 5 March 2019. Regards, Marco Schmidt Policy Officer

28 102

Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing, IPv4 Allocations to a /24)
by Willy MANGA 09 Feb '19

09 Feb '19

Hi, > From: Peter Hessler <phessler(a)theapt.org> > Then come back when you have a solution to force GitHub, Twitter, > Amazon, and a lot more, to launch an IPv6 version of their website. Hopefully it will come soon. At least all have already v6 prefixes used 'inside' their own networks ..

1 0

Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing, IPv4 Allocations to a /24)
by Willy MANGA 09 Feb '19

09 Feb '19

Hi, >[...] > From: Carlos Fria?as <cfriacas(a)fccn.pt> > [...] > I've been deploying and advocating IPv6 since 2001. Others have been doing > it for a longer period. Within this timespan, i have only read about *one* > organisation which publicly expressed plans to scrap IPv4 from their > network/services, but they have dropped that in the meanwhile... Please don't tell me it's the IPv4 disposal technician [1] team :) 1. https://youtu.be/cNMQUCeNW78?t=2176 -- Willy Manga @ongolaboy https://ongola.blogspot.com/

1 0

Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)
by Gert Doering 08 Feb '19

08 Feb '19

Hi, On Fri, Feb 08, 2019 at 04:28:42PM +0100, Corin Langosch wrote: > further why this should be a problem? Usage based billing is very much "usage based" is "you pay for the amount of work and other costs you create at the NCC", which is about what we have now. What you are describing is "sale of goods" - and that is a problem because it would make the addresses the NCC has in stock a taxable asset. 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

4 3

Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)
by Gert Doering 08 Feb '19

08 Feb '19

Hi, On Fri, Feb 08, 2019 at 04:52:29PM +0100, Bernd Sontheimer wrote: > But i don't see that every RIPE member has to pay exactly the same part > as all others. In the beginning we had different registry sizes, XS, S, > M and L with different fees, according to the hold address space. I > think this can and should reflect the different amount of work for > maintenance and services according to the member size. Why is this no > longer possible? Why do we as an operator with 10000 customers exactly > the same fee as one with 10 Mio. customers and much more adress space > (and much more revenue)? I think fair would be a base fee for every > member and an additional fee which is variable depending on the size of > the hold adress space. That has nothing to do with "selling address" > space, but shares only the yearly cost proportional according to the > size of the members. Not necessarily disagreeing with you that there might be good arguments for "who pays not so much" vs. "who pays more". Now, I doubt that a large carrier that has everything automated causes as much cost at the NCC as a new LIR that opens a support ticket twice a month... so, shall the new LIR pay twice the amount that DTAG pays? But anyway: as Jim Reid correctly remarked, this is a different thread, *and* doesn't belong into APWG anyway. Fees are a member business, and need to be voted on in the member meeting (AGM) and discussed on the ripe-members list. So: please stop this particular sub-discussion on the APWG list. Gert Doering -- APWG chair -- 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

1 0

Re: [address-policy-wg] can deadbeat LIRs reverse IPv4 exhaustion?
by Gert Doering 07 Feb '19

07 Feb '19

Hi, On Thu, Feb 07, 2019 at 10:14:18AM +0000, Jim Reid wrote: > Besides, there???s no mechanism or policy for the NCC to recover addresses from LIRs that don???t pay their bills. If such mechanisms or policies existed, they???d be unworkable. There???s no way of knowing for sure that those addresses weren???t being used. So if they were reclaimed, the addresses couldn???t be allocated to someone else. Uh. There actually is - if a LIR stops paying their NCC member fees, the LIR account will be closed, and the address space will be reclaimed. After sufficient quarantaine, the addresses will be allocated to someone else. (There is no mechanism to reclaim addresses from LIR that "do not use them", because they were given out under policies that had no such clause - but that's different from "LIRs that don't pay their bills") Gert Doering -- APWG chair -- 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

1 0

2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) (fwd)
by Carlos Friaças 06 Feb '19

06 Feb '19

I was unaware about this list limitation, but hope this helps... :-) Regards, Carlos ========= Date: Tue, 5 Feb 2019 18:18:45 From: Michael Kafka <mika(a)net-cat.at> To: address-policy-wg(a)ripe.net Subject: [address-policy-wg] New on this list, cannot reply to old topic Hi everyone, I'd like to join the discussion here on the list but I just registered so I can't reply to the existing topic and I don't want to start a new thread. For the sake of a clean thread, can someone please reply to: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) Thanks, MiKa ---------- Forwarded message ---------- Date: Mon, 4 Feb 2019 12:04:26 From: Marco Schmidt <mschmidt(a)ripe.net> To: "address-policy-wg(a)ripe.net" <address-policy-wg(a)ripe.net> Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) Dear colleagues, A new RIPE Policy proposal, 2019-02, "Reducing IPv4 Allocations to a /24" is now available for discussion. This proposal aims to reduce the IPv4 allocation size to a /24 once the RIPE NCC is unable to allocate contiguous /22 ranges. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-02 As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal. We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 5 March 2019. Regards, Marco Schmidt Policy Officer

3 3

New on this list, cannot reply to old topic
by Michael Kafka 05 Feb '19

05 Feb '19

Hi everyone, I'd like to join the discussion here on the list but I just registered so I can't reply to the existing topic and I don't want to start a new thread. For the sake of a clean thread, can someone please reply to: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) Thanks, MiKa

1 0

Re: [address-policy-wg] 2019-01 New Policy Proposal (Clarification of Definition for "ASSIGNED PA")
by Sonderegger Olaf ABRAXAS 29 Jan '19

29 Jan '19

Dear all I support the clarification, less confusion is always better. Best regards, Olaf -- Olaf Sonderegger dipl. Ing. FH / MAS in Corporate Innovation Management Chief Operations Architect Infrastructure & Outsourcing Abraxas Informatik AG Waltersbachstrasse 5 | CH-8006 Zürich Direct +41 58 660 44 94 | Mobil +41 79 708 70 86 olaf.sonderegger(a)abraxas.ch | www.abraxas.ch ---------------------------------------------------------------- Date: Mon, 28 Jan 2019 12:07:17 +0100 From: Andreas Worbs <anw(a)artfiles.de> To: address-policy-wg(a)ripe.net Subject: Re: [address-policy-wg] 2019-01 New Policy Proposal (Clarification of Definition for "ASSIGNED PA") Message-ID: <7192043c-33f4-9a55-42df-ceb95ea82c06(a)artfiles.de> Content-Type: text/plain; charset="utf-8" +1 Am 24.01.19 um 10:35 schrieb Dominik Nowacki: > Dear Colleagues, > We are in support of this proposal. > > With Kind Regards,? > Dominik Nowacki? > ? > Clouvider Limited is a limited company registered in England and > Wales. Registered number:?_08750969_ <tel:08750969>. Registered > office:?_88 Wood Street, London, United Kingdom, EC2V 7RS_.? > > On 24 Jan 2019, at 07:35, Martin Tonusoo > <martin.tonusoo(a)citictel-cpc.com > <mailto:martin.tonusoo@citictel-cpc.com>> wrote: > >> Hello, >> >> is there any feedback on this proposal? While it is more a >> clarification than an actual policy change, then it might clear some >> confusion to create assignments for?LIR own infrastructure within >> their allocation. >> >> >> Best regards, >> Martin Tonusoo >> IP Network Engineer >> -------------------------- >> ? ? ?CITIC Telecom CPC >> ? ?www.citictel-cpc.com <http://www.citictel-cpc.com> >> -------------------------- >> Direct: +372 622 3321 >> NOC 24/7: +372 622 3300 >> NOC 24/7: +7 495 9815670 >> >> >> --------------------------------------------------------------------- >> --- >> *From: *"Marco Schmidt" <mschmidt(a)ripe.net >> <mailto:mschmidt@ripe.net>> >> *To: *"address-policy-wg" <address-policy-wg(a)ripe.net >> <mailto:address-policy-wg@ripe.net>> >> *Sent: *Thursday, January 17, 2019 3:00:50 PM >> *Subject: *[address-policy-wg] 2019-01 New Policy Proposal >> (Clarification of Definition for "ASSIGNED PA") >> >> Dear colleagues, >> >> A new RIPE Policy proposal, 2019-01, "Clarification of Definition for >> "ASSIGNED PA"" is now available for discussion. >> >> This proposal aims to make it clear in the IPv4 Policy that the >> status "ASSIGNED PA" can also be used for assignments to an LIR's >> infrastructure. >> >> You can find the full proposal at: >> https://www.ripe.net/participate/policies/proposals/2019-01 >> >> As per the RIPE Policy Development Process (PDP), the purpose of this >> four week Discussion Phase is to discuss the proposal and provide >> feedback to the proposer. >> >> At the end of the Discussion Phase, the proposer, with the agreement >> of the WG Chairs, will decide how to proceed with the proposal. >> >> We encourage you to review this proposal and send your comments to >> <address-policy-wg(a)ripe.net <mailto:address-policy-wg@ripe.net>> >> before 15 February 2019. >> >> Regards, >> >> Marco Schmidt >> Policy Officer >> RIPE NCC -- Mit freundlichem Gru? Artfiles New Media GmbH Andreas Worbs Artfiles New Media GmbH | Zirkusweg 1 | 20359 Hamburg Tel: 040 - 32 02 72 90 | Fax: 040 - 32 02 72 95 E-Mail: support(a)artfiles.de | Web: http://www.artfiles.de Gesch?ftsf?hrer: Harald Oltmanns | Tim Evers Eingetragen im Handelsregister Hamburg - HRB 81478

1 0

2019-01 New Policy Proposal (Clarification of Definition for "ASSIGNED PA")
by Marco Schmidt 28 Jan '19

28 Jan '19

Dear colleagues, A new RIPE Policy proposal, 2019-01, "Clarification of Definition for "ASSIGNED PA"" is now available for discussion. This proposal aims to make it clear in the IPv4 Policy that the status "ASSIGNED PA" can also be used for assignments to an LIR's infrastructure. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-01 As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal. We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 15 February 2019. Regards, Marco Schmidt Policy Officer RIPE NCC

4 3

Re: [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification
by JORDI PALET MARTINEZ 20 Jan '19

20 Jan '19

Hi Ray, The question of the DC is much more complex. I think. For example, is the same if the "hardware" (the real servers) are from the assignment holder or from third parties? (hosting vs housing). I think hosting will be ok from the perspective of both the original IPv6 PI policy and the actual one. However, housing is at least, "in the limit" of what was intended originally ("not to be sub-assigned to other parties "). With the actual policy both are allowed, but housing seems to be allowed only if dynamic ("connecting a server or appliance to an assignment holder's network") according to the impact analysis. This doesn't make sense, because if I'm setting up a server or appliance, it is not (in most of the cases) a "temporary" thing. Also, the use of dynamic, may be confusing vs "persistent" (as we used in RIPE-690), as it may confuse regarding the usage of DHCP or something else, etc. I think this must be allowed, even if static/persistent, because I may need a service company coming to my network with their own devices, for example, installing IP video-cameras for surveillance. It doesn't make sense that they can't use my addresses, because that increase the complexity of the infrastructure, etc., even may force to have different networks. Regards, Jordi -----Mensaje original----- De: address-policy-wg <address-policy-wg-bounces(a)ripe.net> en nombre de Jetten Raymond <raymond.jetten(a)elisa.fi> Fecha: jueves, 17 de enero de 2019, 14:03 Para: JORDI PALET MARTINEZ <jordi.palet(a)consulintel.es> CC: "address-policy-wg(a)ripe.net" <address-policy-wg(a)ripe.net> Asunto: Re: [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification Hello All, I have a maybe very strange opinion on this, so i'll share it with you. I agree with Jordi that the current situation is confusing and could be clearer... IPv6 PI should be used as very originally was intended, and it should not be subnetted or subdelegations should be made of it to other instances than the obtainer at all. Before you turn on the grill, what should be changed or made allowed or understood as intention, compared to the very original intention of PI IPv6 is that the temporary use as in f.ex your guest wlan, (the enduser will not get these ip:s with him/her when leaving the building, it’s a WLAN infrastructure that can be used as a "client" in this case even temporary). In a DC, as long as the infra and servers are used or more precisely accessed by clients, they also do not get the ip:s assigned, but use them to access these platforms. In these cases the ip subnets belong to the provider, not to the customer. (VPN is a service right?) If a customer of a DC needs an assigned block for whatever reason, they can obtain a normal v6 block , or if PI v6 is needed, its still available, apply for a PI v6 subnet from Ripe. (or even become a member). I hope this helps Rgds, Ray -----Original Message----- From: address-policy-wg <address-policy-wg-bounces(a)ripe.net> On Behalf Of JORDI PALET MARTINEZ via address-policy-wg Sent: 17. tammikuuta 2019 14:13 To: address-policy-wg <address-policy-wg(a)ripe.net> Subject: [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification Hi all, As you know, I've been working on different versions of a clarification to 2016-04 (https://www.ripe.net/participate/policies/proposals/2016-04). This proposal allows a single IP to be sub-assigned, and the author explained (not just in the policy proposal text, but also in the justification and in different emails), that the case they have is to make sure that the policy allows it for: 1) Datacenter services. 2) Interconnections (VPN, PNI, p2p, etc.). 3) Guess visitors (employees, hotspot users, etc.). The policy text doesn't mention those examples, but the summary talks about them: "Intended use cases for IPv6 PI space in the spirit of this policy proposal are the use in (public) WIFI networks (like the WIFI at RIPE meetings), as transfer networks on PNIs or other PTP-links/VPNs to users or customers, or for housing/hosting for servers in data centres. The use of IPv6 PI space for DSL/cable/FFTH/etc. subscribers is explicitly not an intended use case for this policy proposal." On the other side, the impact analysis indicates: "It is the RIPE NCCs understanding that assignments as described above are dynamic in nature, either by varying the prefix or interface identifier (IID) over time. Any permanent and static assignments of a prefix would still be considered a sub-assignment as per clause 2.6, “Assign” of the IPv6 address allocation and assignment policy. Consequently the RIPE NCC will not provide IPv6 PI assignments for such deployment plans." I don't think this is very clear, because 1) DC addresses usually are static. 2) Interconnections usually are static (p2p links at least). On the other side, as explained in my previous versions, I think that it is a valid case (in a hotspot, DC, etc.), instead of providing a single address, provide a full prefix (for example /64), so the host can have Virtual Machines running on different addresses of the same prefix. So, in my understanding we really need to clarify this text and for that, we need to decide what we want to be allowed and what not. So my questions are: 1) Do we agree that only dynamic should be allowed, or static is also ok? 2) According to 1 above, should the DataCenter case be alllowed? Thanks! Regards, Jordi ********************************************** 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. ********************************************** 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.

5 11

suggestions from the list about IPv6 sub-assignment clarification
by JORDI PALET MARTINEZ 17 Jan '19

17 Jan '19

Hi all, As you know, I've been working on different versions of a clarification to 2016-04 (https://www.ripe.net/participate/policies/proposals/2016-04). This proposal allows a single IP to be sub-assigned, and the author explained (not just in the policy proposal text, but also in the justification and in different emails), that the case they have is to make sure that the policy allows it for: 1) Datacenter services. 2) Interconnections (VPN, PNI, p2p, etc.). 3) Guess visitors (employees, hotspot users, etc.). The policy text doesn't mention those examples, but the summary talks about them: "Intended use cases for IPv6 PI space in the spirit of this policy proposal are the use in (public) WIFI networks (like the WIFI at RIPE meetings), as transfer networks on PNIs or other PTP-links/VPNs to users or customers, or for housing/hosting for servers in data centres. The use of IPv6 PI space for DSL/cable/FFTH/etc. subscribers is explicitly not an intended use case for this policy proposal." On the other side, the impact analysis indicates: "It is the RIPE NCCs understanding that assignments as described above are dynamic in nature, either by varying the prefix or interface identifier (IID) over time. Any permanent and static assignments of a prefix would still be considered a sub-assignment as per clause 2.6, “Assign” of the IPv6 address allocation and assignment policy. Consequently the RIPE NCC will not provide IPv6 PI assignments for such deployment plans." I don't think this is very clear, because 1) DC addresses usually are static. 2) Interconnections usually are static (p2p links at least). On the other side, as explained in my previous versions, I think that it is a valid case (in a hotspot, DC, etc.), instead of providing a single address, provide a full prefix (for example /64), so the host can have Virtual Machines running on different addresses of the same prefix. So, in my understanding we really need to clarify this text and for that, we need to decide what we want to be allowed and what not. So my questions are: 1) Do we agree that only dynamic should be allowed, or static is also ok? 2) According to 1 above, should the DataCenter case be alllowed? Thanks! Regards, Jordi ********************************************** 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 2

Re: [address-policy-wg] definition of "ASSIGNED PA" in IPv4 address allocation and assignment policy
by Erik Bais 21 Dec '18

21 Dec '18

Hi Martin, If you look at the text, would the LIR who assigned IP space to their own infra-structure not also be an End-User ? In the past, the LIR would describe IP space for themselves as Infra or INFRA-AW, but still give it the status Assigned PA. Something along the lines of this example : https://apps.db.ripe.net/db-web-ui/#/lookup?source=ripe&key=178.249.152.0%2… Regards, Erik Bais From: address-policy-wg <address-policy-wg-bounces(a)ripe.net> on behalf of Martin Tonusoo <martin.tonusoo(a)citictel-cpc.com> Date: Tuesday 13 November 2018 at 13:42 To: "address-policy-wg(a)ripe.net" <address-policy-wg(a)ripe.net> Subject: [address-policy-wg] definition of "ASSIGNED PA" in IPv4 address allocation and assignment policy Hello, according to "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region"(ripe-708) document, the "status" attribute value "ASSIGNED PA" has a definition of "This address space has been assigned to an End User for use with services provided by the issuing LIR". As "ASSIGNED PA" should also be used for assignments for LIR own infrastructure, then isn't the definition of "This address space has been assigned to the issuing LIR infrastructure or End User for use with services provided by the issuing LIR." bit more accurate? Best regards, Martin Tonusoo IP Network Engineer -------------------------- CITIC Telecom CPC www.citictel-cpc.com -------------------------- Direct: +372 622 3321 NOC 24/7: +372 622 3300 NOC 24/7: +7 495 9815670

2 3

Policy violation
by Aleksey Bulgakov 18 Dec '18

18 Dec '18

Hello. On the 7th of September the NCC implemeted the document https://www.ripe.net/publications/docs/ripe-709#transfer35 (The document is published on the 21th of September). The support clarify it that you cannot merge one LIR into the second LIR in case of M&A procedure because of the 24 month resource transfer restriction. However there is another document https://www.ripe.net/publications/docs/ripe-682#2-2-transfer… where you can read the next: 2.2 Transfer Restrictions This restriction does not prevent the resources from being transferred due to further mergers or acquisitions within the 24-month period. In this case the NCC doesn't follow own policies. Or am I wrong? I though the NCC should create the proposal to make changes to the transfer policies but don't implement unclear documents by the executive board consisting of 7 people. Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

12 19

Fwd: Policy violation
by Uros Gaber 18 Dec '18

18 Dec '18

Dear Aleksey, Maybe you miss the point of having IPv4 resources (at this time). It is not to resell and make a profit, but to use where the resources are scarce, I think we can (still) be happy that RIPE and its members have made a good job until now so that any new LIR has some IPv4 resources at their disposal. Kind regards, Uros Gaber On Tue, Dec 18, 2018 at 11:31 AM Aleksey Bulgakov <aleksbulgakov(a)gmail.com> wrote: > I think the NCC wants to have Monopoly for IP selling and doesn't want to > devide profit with anyone. > > Of course it has more profit if there are more members with multiple > accounts or many different accounts of different legal entities witch will > pay for many years later. > > вт, 18 дек. 2018 г., 12:40 Gert Doering gert(a)space.net: > >> Hi, >> >> On Tue, Dec 18, 2018 at 12:37:40PM +0300, Aleksey Bulgakov wrote: >> > So then the NCC will say that it's non-commercial organization. >> >> This is not about making money. It is about making it clear that >> you can't just get cheap /22s from the RIPE NCC. >> >> But you know all that. >> >> 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 >> >

1 0

definition of "ASSIGNED PA" in IPv4 address allocation and assignment policy
by Martin Tonusoo 13 Nov '18

13 Nov '18

Hello, according to "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region"(ripe-708) document, the "status" attribute value "ASSIGNED PA" has a definition of "This address space has been assigned to an End User for use with services provided by the issuing LIR". As "ASSIGNED PA" should also be used for assignments for LIR own infrastructure, then isn't the definition of "This address space has been assigned to the issuing LIR infrastructure or End User for use with services provided by the issuing LIR." bit more accurate? Best regards, Martin Tonusoo IP Network Engineer -------------------------- CITIC Telecom CPC www.citictel-cpc.com -------------------------- Direct: +372 622 3321 NOC 24/7: +372 622 3300 NOC 24/7: +7 495 9815670

1 0

Re: [address-policy-wg] Policies and Guidelines for Assignments for Network Infrastructure and End User Networks
by Marco Schmidt 07 Nov '18

07 Nov '18

Dear Töma, Thank you for your questions. Please allow me to provide some clarification. Regarding our LIR Training Course - it's important to note that this is intended to help people fulfil their role as representatives of a member. Our training courses do not provide a different interpretation of RIPE policies ("either more strict or more relaxed") - but rather represent the shared understanding and practices of network operators in the RIPE community. That being said, we are constantly reviewing our training material and will take another look at this with your feedback in mind. Nick and Leo have already provided some clarification around the historical context of section 6.2 of the policy (ripe-708). We agree with their comments and there's not much we can add beyond this. If you feel that the wording in this section is ambiguous, we invite you to make use of the Policy Development Process to propose a change to the policy. I will be happy to follow-up with you offline to provide more details and guidance to help you create a policy proposal. Kind regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

1 0

Policies and Guidelines for Assignments for Network Infrastructure and End User Networks
by Töma Gavrichenkov 05 Nov '18

05 Nov '18

Hello WG (both, actually), A recent case of a Russian broadband ISP, roughly 6th in size in the country, exposing the personal data of their individual VIP customers by posting said data to RIPE DB(*) highlighted an important issue in RIPE-708, 6.2 "[policies and guidelines for assignments for] Network Infrastructure and End User Networks"(**). To quote: > IP addresses used solely for the connection of an End User to a service provider (e.g. point-to-point links) are considered part of the service provider's infrastructure. These addresses do not have to be registered with the End User's contact details but can be registered as part of the service provider's internal infrastructure. > When an End User has a network using public address space this _must_ be registered separately with the contact details of the End User. Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End Users. (note the "must", we'll soon get back to it) While it's out of question that posting individual users' personal data to RIPE DB is insane, what's interesting is that small business owners(***), when aware of the leak, seem to also be concerned that their B2B broadband data contract apparently included a clause they've missed, and their mobile telephone number is now published to a public database on the Internet, and, you know, one cannot simply remove an information from the Internet which is already there. But when we try to rely on 6.2 for a definitive advice, we don't get any: - There's no definition of what is exactly meant under "point-to-point links" (PTPL). Some speculate it's a historical term from the times of PPP/SLIP, meaning just "end-user access links", and, as such, includes individual and SMB customer links. Other read it as those IPv4 /30s ASes waste all the time for BGP session establishment, and argue that what's really meant by PTPL is just the IP addresses never ever communicating with the world outside of their own local net (BGP sessions included, SMB access obviously not included). (Personally, the second opinion looks more convincing for me, because this way only those IP addresses which never send or receive packets from the Internet may lack a proper abuse-c, which makes sense, and I like when things make sense, so. But at the same time the first opinion is backed by people I respect.) Anyway, RIPE-708 fails to provide an answer. - Another scary term is "a network using public address space" (NUPAS). Is IPv4 /32 a network? What about /31? What's "using public address space" after all, there's no doubt we won't report our usage of 192.168.0.0/16 to RIPE DB. This sentence was meant to clear our concerns but it just adds up to them. What is also meant to help us but adds to the mess is the RIPE NCC Local Internet Registry Training Course(****), slides 94-95: - Somehow, training material includes more specific definitions and corner cases (e.g. "points of presence") than the policy does. Is it only me, or such a thing should never ever happen? A policy training course must not be different from the policy itself, no matter if the difference is in being either more strict of more relaxed. If an NCC trainer just knows more about the subject than is stated in a policy, they'd better report to the WG first that the policy lacks an important consideration. - However, those definitions don't really clarify what's PTPL and NUPAS are, too. - Slide 95 is even better: it says there's a grey area around. Well, it might be again only me, but personally I feel very uncomfortable seeing "must" and "grey area" in the same sentence. If there's a grey area in an area, it must be "should" there, not "must". - There's apparently a border line between "when the End User has a few addresses out of a larger address block" and "If the End User has a separate subnet". Now again, (an occasional?) /31 is a subnet or just a few addresses? Who's going to check ISPs against this strict ("must") requirement, and how? - What if there's a customer with an pizza store (so, an office within their location) and their own equipment (Mikrotik) connected to a broadband pool? - What if a broadband customer sets up an HTTP server on their point-to-point link's public v4 address and starts serving whatever children drug suicide abuse torrents they have. All in all, RIPE-708 6.2 is a perfect example of an imperfect policy, too strict and too vague at the same time. Which is bad, because a) some ISPs would just prefer to ignore it, no matter the "must", and would be paying less attention to other "musts" they would encounter in other policy documents, b) those ISPs who would choose to be responsible about RIPE DB usage risk losing customers and wouldn't be able to defend their attitude against the customers, let alone courts, based on the RIPE DB policy. So here are two separate things I propose, and I'd prefer them to be discussed and evaluated separately: 1) Ask the author of LIR training material to provide the WG (both) with the historical insight on what was meant in 6.2, and how's that supposed to work. Afterwards, after a heated discussion on the mailing list (both), make a decision and amend a policy towards either a more relaxed, or a more constraining fashion, but do either of things anyway, as there's no SLIP anymore, and such an irresponsible wording of a policy as it stands today undermines the trust in policy process, especially in some Eastern European and Northeast countries where there's hardly any trust even now. My personal suggestion is that the only border line that should be there is between businesses/organizations with public IP addresses, on one side, and individual users/NAT pools, on the other. If a company is using a public IP address space for any purpose at all, it must publish at least an abuse-c contact to a public IP database. Fair enough IMO. 2) Change 6.2 to reflect the fact that the contact information of End Users who are individuals not MAY, but rather MUST be substituted with the contact data of the service provider. This perfectly reflects currently ongoing legislation trends as well as a concern in the society at large, and also would be seen as a responsible attitude of an ISP community towards the personal data safety — an attitude the ISP community hardly used to show before. (*) — https://www.bbc.com/russian/news-46083410. Here's a Google Translate link for your convenience: https://translate.google.com/translate?sl=ru&tl=en&js=n&u=https%3A%2F%2Fwww… (**) — https://www.ripe.net/publications/docs/ripe-708#62 (***) — My definition of a "small business" here might seem too broad, but if's fully grounded: e.g. Main Directorate for Drugs Control of the Ministry of Internal Affairs of Russia, as a business, is definitely not so big; Alfa Bank is a large bank in Russia but Russian banking system is comparatively small when compared to the rest of the world; etc. (****) — https://www.ripe.net/support/training/material/lir-training-course/lir-slid… | Töma Gavrichenkov | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 | mailto: ximaera(a)gmail.com | fb: ximaera | telegram: xima_era | skype: xima_era | tel. no: +7 916 515 49 58

4 6

proposed text for Assignment Clarification in IPv6 Policy (policy proposal 2018-02)
by JORDI PALET MARTINEZ 29 Oct '18

29 Oct '18

Hi all, Unfortunately, I've not received inputs on my question about what we want to be allowed in IPv6 PI, but as I'm working on this in other regions, got inputs in another region, which I think I can translate to this text: ** 2.6. Assign To "assign" means to delegate address space to an ISP or End User, for exclusive use within the infrastructure they operate, as well as for interconnection purposes. The address space assignment is only for use by the original holder of said assignment, as well as for third-party devices, as long as they are operating within the original holder infrastructure. PI space will provide typically, a small number of subnets, so it is not intended or desired to use PI space for access networks or commercial hosting and it is strongly recommended instead, using PA space for such purposes. ** This allows us to be "liberal" on using PI for data centers, which I think is the main issue of my previous version (https://www.ripe.net/participate/policies/proposals/2018-02), and also allow what somebody said is a "garage ISP" (a small ISP or DC that can start with very small cost o PI, and grow later on to PA). This will also align us with the goal of facilitating IPv6 deployment. Opinions? Regards, Jordi ********************************************** 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.

1 0

country code in ORGANISATION object
by denis walker 22 Oct '18

22 Oct '18

Hi all During the questions after Ingrid's presentation about the meaning of country codes it was mentioned that both the ORGANISATION and INET(6)NUM objects had a "country:" attribute. The suggestion was that maybe the one in the ORGANISATION object could reflect a legal country and the resources could be user specific. I can't see any mention anywhere of a "country:" attribute in an ORGANISATION object. It might be useful if it had one especially for the current discussion in NCC Services about legal address. cheersdenis

5 6

What we want to be acceptable in IPv4 PI and IPv6 PI?
by JORDI PALET MARTINEZ 17 Oct '18

17 Oct '18

Hi all, Trying to look into my presentation today from a higher-level perspective ... What is the expected usage of IPv4 and IPv6 PI? It should be the same or different? Do we want to use IPv6 PI as an entry point for people, without any restrictions, to start providing services and then they can grow up to become an LIR? That means that an IPv6 PI can be used to provide hosting/housing services? What about broadband services to end-users? Peter, maybe you have a different perspective about how to approach this. Can you share it in the list? Regards, Jordi ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es 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 4

2018-02 Discussion Phase Extended (Assignment Clarification in IPv6 Policy)
by Marco Schmidt 03 Oct '18

03 Oct '18

Dear colleagues, RIPE Policy proposal 2018-02, "Assignment Clarification in IPv6 Policy" is still available for discussion. This proposal aims to clarify the definition of "Assign" in the IPv6 Policy (ripe-707, section 2.6). You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2018-02 As per the RIPE Policy Development Process (PDP), the purpose of this three week extended Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal. We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 25 October 2018. Regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

1 0

RIPE 76 Address Policy WG Draft Minutes
by Marco Schmidt 02 Oct '18

02 Oct '18

Dear colleagues, The draft minutes from the Address Policy Working Group sessions at RIPE 76 have now been published: https://www.ripe.net/participate/ripe/wg/ap/minutes/ripe-76-address-policy-… Please let us know of any corrections or amendments. Kind regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

1 0