January 2019 - address-policy-wg

New on RIPE Labs: So Long Last /8 and Thanks For All the Allocations
by Mirjam Kuehne 28 Aug '19

28 Aug '19

Dear colleagues, On 17 April 2018, we allocated the last available block of 1,024 addresses in 185/8 - the last /8 we received from IANA back in 2011. This article on RIPE Labs looks at how this address space was allocated and how it is used today: https://labs.ripe.net/Members/wilhelm/so-long-last-8-and-thanks-for-all-the… It's important to keep in mind that while 185/8 is finished, we still have around nine million recovered IPv4 addresses in our available pool. Under current policy and growth rates, we expect these to last a further two years. Kind regards, Mirjam Kühne RIPE NCC

3 2

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