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

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