From jordi.palet at consulintel.es Thu Jan 17 13:12:36 2019 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 17 Jan 2019 13:12:36 +0100 Subject: [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification Message-ID: <13143A92-7AC3-4864-B459-622A04A3CB42@consulintel.es> 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. From gert at space.net Thu Jan 17 13:34:35 2019 From: gert at space.net (Gert Doering) Date: Thu, 17 Jan 2019 13:34:35 +0100 Subject: [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification In-Reply-To: <13143A92-7AC3-4864-B459-622A04A3CB42@consulintel.es> References: <13143A92-7AC3-4864-B459-622A04A3CB42@consulintel.es> Message-ID: <20190117123435.GX1543@Space.Net> Hi, thanks, Jordi, to get the ball rolling again on this. On Thu, Jan 17, 2019 at 01:12:36PM +0100, JORDI PALET MARTINEZ via address-policy-wg wrote: > 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? These are indeed the questions we need to have at least some semblance of agremeent upon before we can try to make policy text out of it. While I do have an opinion, I'm not going to voice it now :-) - so, folks, what do *you* think? 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From mschmidt at ripe.net Thu Jan 17 14:00:50 2019 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 17 Jan 2019 14:00:50 +0100 Subject: [address-policy-wg] 2019-01 New Policy Proposal (Clarification of Definition for "ASSIGNED PA") Message-ID: <4dd3fbae-6e64-ccad-2c41-62a7ef392394@ripe.net> 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 before 15 February 2019. Regards, Marco Schmidt Policy Officer RIPE NCC From raymond.jetten at elisa.fi Thu Jan 17 14:03:27 2019 From: raymond.jetten at elisa.fi (Jetten Raymond) Date: Thu, 17 Jan 2019 13:03:27 +0000 Subject: [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification In-Reply-To: <13143A92-7AC3-4864-B459-622A04A3CB42@consulintel.es> References: <13143A92-7AC3-4864-B459-622A04A3CB42@consulintel.es> Message-ID: 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 On Behalf Of JORDI PALET MARTINEZ via address-policy-wg Sent: 17. tammikuuta 2019 14:13 To: address-policy-wg 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. From jordi.palet at consulintel.es Thu Jan 17 14:21:38 2019 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 17 Jan 2019 14:21:38 +0100 Subject: [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification Message-ID: <7C952EEF-C67E-4A3A-962C-DD2B0DF06A24@consulintel.es> 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 en nombre de Jetten Raymond Fecha: jueves, 17 de enero de 2019, 14:03 Para: JORDI PALET MARTINEZ CC: "address-policy-wg at 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 On Behalf Of JORDI PALET MARTINEZ via address-policy-wg Sent: 17. tammikuuta 2019 14:13 To: address-policy-wg 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. From raymond.jetten at elisa.fi Thu Jan 17 14:40:53 2019 From: raymond.jetten at elisa.fi (Jetten Raymond) Date: Thu, 17 Jan 2019 13:40:53 +0000 Subject: [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification In-Reply-To: <7C952EEF-C67E-4A3A-962C-DD2B0DF06A24@consulintel.es> References: <7C952EEF-C67E-4A3A-962C-DD2B0DF06A24@consulintel.es> Message-ID: # commented -----Original Message----- From: JORDI PALET MARTINEZ Sent: 17. tammikuuta 2019 15:22 To: Jetten Raymond Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification 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. #True, so in that case when you set up a server in the DC of someone else and need v6PI get your own block from the RIPE NCC ?? But yes I understand there can be more complicated situations.... 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 en nombre de Jetten Raymond Fecha: jueves, 17 de enero de 2019, 14:03 Para: JORDI PALET MARTINEZ CC: "address-policy-wg at 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 On Behalf Of JORDI PALET MARTINEZ via address-policy-wg Sent: 17. tammikuuta 2019 14:13 To: address-policy-wg 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. From wusel+ml at uu.org Thu Jan 17 15:09:49 2019 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Thu, 17 Jan 2019 15:09:49 +0100 Subject: [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification In-Reply-To: <7C952EEF-C67E-4A3A-962C-DD2B0DF06A24@consulintel.es> References: <7C952EEF-C67E-4A3A-962C-DD2B0DF06A24@consulintel.es> Message-ID: <14721D70-B227-4287-BACE-E3216D3A1EA4@uu.org> Am 17. Januar 2019 14:21:38 MEZ schrieb JORDI PALET MARTINEZ via address-policy-wg : >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. Nicely constructed, but ... usually you will not have them come to your site, let them install their gear out of blue sky, and just leave. You'll have some kind of contractual relationship in place to have them do something for you, making the devices part of your network for the time being, so assigning them PIv6 addresses is ok (they are part of End User's infrastructure at that time ? if you are the receiving End User of the PIv6 in question). Regards, -kai From jordi.palet at consulintel.es Thu Jan 17 15:17:59 2019 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 17 Jan 2019 15:17:59 +0100 Subject: [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification In-Reply-To: <14721D70-B227-4287-BACE-E3216D3A1EA4@uu.org> References: <7C952EEF-C67E-4A3A-962C-DD2B0DF06A24@consulintel.es> <14721D70-B227-4287-BACE-E3216D3A1EA4@uu.org> Message-ID: <501AA242-0828-4816-9CA6-E8880CEECD24@consulintel.es> And I agree with all what you said! I just want to make sure that we all are in the same page. Regards, Jordi ?-----Mensaje original----- De: address-policy-wg en nombre de Kai 'wusel' Siering Fecha: jueves, 17 de enero de 2019, 15:10 Para: JORDI PALET MARTINEZ via address-policy-wg Asunto: Re: [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification Am 17. Januar 2019 14:21:38 MEZ schrieb JORDI PALET MARTINEZ via address-policy-wg : >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. Nicely constructed, but ... usually you will not have them come to your site, let them install their gear out of blue sky, and just leave. You'll have some kind of contractual relationship in place to have them do something for you, making the devices part of your network for the time being, so assigning them PIv6 addresses is ok (they are part of End User's infrastructure at that time ? if you are the receiving End User of the PIv6 in question). Regards, -kai ********************************************** 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. From jordi.palet at consulintel.es Thu Jan 17 15:37:12 2019 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 17 Jan 2019 15:37:12 +0100 Subject: [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification In-Reply-To: References: <7C952EEF-C67E-4A3A-962C-DD2B0DF06A24@consulintel.es> Message-ID: If we agree that *persistent* addresses can be provided, my opinion is that then it is just fine to have your machines in my infrastructure, using my addresses. If you tomorrow move your machines to another place, you will not be able to keep using my addresses. So of course, either from day one, or when you move, you have the chance to get your own IPv6 PI block. We need to consider as well, as I depicted already before, that if you have a physical sever, you probably need also multiple addresses for that server, that's why, I think the policy should allow that (this is clearly now allowed now). Regards, Jordi ?-----Mensaje original----- De: address-policy-wg en nombre de Jetten Raymond Fecha: jueves, 17 de enero de 2019, 14:41 Para: JORDI PALET MARTINEZ CC: "address-policy-wg at ripe.net" Asunto: Re: [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification # commented -----Original Message----- From: JORDI PALET MARTINEZ Sent: 17. tammikuuta 2019 15:22 To: Jetten Raymond Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification 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. #True, so in that case when you set up a server in the DC of someone else and need v6PI get your own block from the RIPE NCC ?? But yes I understand there can be more complicated situations.... 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 en nombre de Jetten Raymond Fecha: jueves, 17 de enero de 2019, 14:03 Para: JORDI PALET MARTINEZ CC: "address-policy-wg at 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 On Behalf Of JORDI PALET MARTINEZ via address-policy-wg Sent: 17. tammikuuta 2019 14:13 To: address-policy-wg 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. ********************************************** 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. From wusel+ml at uu.org Thu Jan 17 20:15:59 2019 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Thu, 17 Jan 2019 20:15:59 +0100 Subject: [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification In-Reply-To: References: <7C952EEF-C67E-4A3A-962C-DD2B0DF06A24@consulintel.es> Message-ID: <2577d148-f96f-93cf-1b68-780d30fa742f@uu.org> On 17.01.2019 15:37, JORDI PALET MARTINEZ via address-policy-wg wrote: > We need to consider as well, as I depicted already before, that if you have a physical sever, you probably need also multiple addresses for that server, that's why, I think the policy should allow that (this is clearly now allowed now). Let's consult ripe-707: > > 2.6. Assign > > To ?assign? means to delegate address space to an ISP or End User for specific use within the Internet infrastructure they operate. Assignments must only be made for specific purposes documented by specific organisations and are not to be sub-assigned to other parties. > > Providing another entity with separate addresses (not prefixes) from a subnet used on a link operated by the assignment holder is not considered a sub-assignment. This includes for example letting visitors connect to the assignment holder's network, connecting a server or appliance to an assignment holder's network and setting up point-to-point links with 3rd parties. > > > 2.9. End Site > > An End Site is defined as an End User (subscriber) who has a business or legal relationship (same or associated entities) with a service provider that involves: > > * that service provider assigning address space to the End User > * that service provider providing transit service for the End User to other sites > * that service provider carrying the End User's traffic > * that service provider advertising an aggregate prefix route that contains the End User's assignment > By these definitions, only an IR ("2.1. Internet Registry (IR)")? can "assign" allocated address space to non-IRs, i. e. ISPs or End Users, in the context of ripe-707. The term "ISP" is not wll defined within ripe-707 except for "LIRs are generally ISPs whose customers are primarily End Users and possibly other ISPs" in "2.4. Local Internet Registry (LIR)". The graph in "2. Definitions" suggests that ISPs are the entities that are actually creating the Internet, whereas (L)IRs are involved in distributing IP space only. Since, following 2.6., only an (I)SP _that also is an (L)IR_ could, acting in it's (L)IR role, "assign" address space, 2.9. should therefore receive a friendly "s/service provider/ISP/g" and have the first bullet point removed. On the other hand, 2.6. in it's current form ? except for the "separate addresses (not prefixes)" issue, as any singke address IS technically also a /128 prefix ? seems rather clear to me: if it's for the documented "specific use within the Internet infrastructure they operate", it's fine. Otherwise, a separate assignment is needed for either a new specific use _or a different End User_, so the ISP or End User (or the ISP for it's End User) will have to request that from an (L)IR (which it may be itself, if the ISP or End User is an LIR as well). Thus, if you need "multiple addresses" for your "physical server" and you received an assignment for your infrastructure including your server(s), I cannot see a conflict with ripe-707. If you want to add a dedicated server for a customer of yours, I'd expect you to get a new (non-PI) prefix (i. e. no less than a /64 as per 5.4.1.) for this different End User from your LIR of choice (or have that End User apply for a /48 PIv6 via your cooperative LIR). Regards, -kai -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Thu Jan 17 20:34:39 2019 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 17 Jan 2019 20:34:39 +0100 Subject: [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification In-Reply-To: <2577d148-f96f-93cf-1b68-780d30fa742f@uu.org> References: <7C952EEF-C67E-4A3A-962C-DD2B0DF06A24@consulintel.es> <2577d148-f96f-93cf-1b68-780d30fa742f@uu.org> Message-ID: Hi Kai, You?re missing that 2016-04 is for the clarification of IPv6 PI, not PA. https://www.ripe.net/participate/policies/proposals/2016-04 Regards, Jordi De: address-policy-wg en nombre de Kai 'wusel' Siering Organizaci?n: Unseen University, Department of Magic Mails Fecha: jueves, 17 de enero de 2019, 20:16 Para: Asunto: Re: [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification On 17.01.2019 15:37, JORDI PALET MARTINEZ via address-policy-wg wrote: We need to consider as well, as I depicted already before, that if you have a physical sever, you probably need also multiple addresses for that server, that's why, I think the policy should allow that (this is clearly now allowed now). Let's consult ripe-707: 2.6. Assign To ?assign? means to delegate address space to an ISP or End User for specific use within the Internet infrastructure they operate. Assignments must only be made for specific purposes documented by specific organisations and are not to be sub-assigned to other parties. Providing another entity with separate addresses (not prefixes) from a subnet used on a link operated by the assignment holder is not considered a sub-assignment. This includes for example letting visitors connect to the assignment holder's network, connecting a server or appliance to an assignment holder's network and setting up point-to-point links with 3rd parties. 2.9. End Site An End Site is defined as an End User (subscriber) who has a business or legal relationship (same or associated entities) with a service provider that involves: ? that service provider assigning address space to the End User ? that service provider providing transit service for the End User to other sites ? that service provider carrying the End User's traffic ? that service provider advertising an aggregate prefix route that contains the End User's assignment By these definitions, only an IR ("2.1. Internet Registry (IR)") can "assign" allocated address space to non-IRs, i. e. ISPs or End Users, in the context of ripe-707. The term "ISP" is not wll defined within ripe-707 except for "LIRs are generally ISPs whose customers are primarily End Users and possibly other ISPs" in "2.4. Local Internet Registry (LIR)". The graph in "2. Definitions" suggests that ISPs are the entities that are actually creating the Internet, whereas (L)IRs are involved in distributing IP space only. Since, following 2.6., only an (I)SP _that also is an (L)IR_ could, acting in it's (L)IR role, "assign" address space, 2.9. should therefore receive a friendly "s/service provider/ISP/g" and have the first bullet point removed. On the other hand, 2.6. in it's current form ? except for the "separate addresses (not prefixes)" issue, as any singke address IS technically also a /128 prefix ? seems rather clear to me: if it's for the documented "specific use within the Internet infrastructure they operate", it's fine. Otherwise, a separate assignment is needed for either a new specific use _or a different End User_, so the ISP or End User (or the ISP for it's End User) will have to request that from an (L)IR (which it may be itself, if the ISP or End User is an LIR as well). Thus, if you need "multiple addresses" for your "physical server" and you received an assignment for your infrastructure including your server(s), I cannot see a conflict with ripe-707. If you want to add a dedicated server for a customer of yours, I'd expect you to get a new (non-PI) prefix (i. e. no less than a /64 as per 5.4.1.) for this different End User from your LIR of choice (or have that End User apply for a /48 PIv6 via your cooperative LIR). Regards, -kai ********************************************** 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wusel+ml at uu.org Thu Jan 17 20:58:43 2019 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Thu, 17 Jan 2019 20:58:43 +0100 Subject: [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification In-Reply-To: References: <7C952EEF-C67E-4A3A-962C-DD2B0DF06A24@consulintel.es> <2577d148-f96f-93cf-1b68-780d30fa742f@uu.org> Message-ID: <4a668701-e63a-8f34-2f37-df25ecc49bbf@uu.org> Hi Jordi, you're mixing things up. This is not about 2016-04, which was approved long time ago. This is about ripe-707 [1], titled "IPv6 Address Allocation and Assignment Policy" ? the current policy in question you want to be modified. Regards, -kai [1] https://www.ripe.net/publications/docs/ripe-707#assign Am 17.01.2019 um 20:34 schrieb JORDI PALET MARTINEZ: > > Hi Kai, > > > > You?re missing that 2016-04 is for the clarification of IPv6 PI, not PA. > > > > https://www.ripe.net/participate/policies/proposals/2016-04 > > > Regards, > > Jordi > > > > > > > > *De: *address-policy-wg en nombre de Kai 'wusel' Siering > *Organizaci?n: *Unseen University, Department of Magic Mails > *Fecha: *jueves, 17 de enero de 2019, 20:16 > *Para: * > *Asunto: *Re: [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification > > > > On 17.01.2019 15:37, JORDI PALET MARTINEZ via address-policy-wg wrote: > > We need to consider as well, as I depicted already before, that if you have a physical sever, you probably need also multiple addresses for that server, that's why, I think the policy should allow that (this is clearly now allowed now). > > > Let's consult ripe-707: > > > 2.6. Assign > > To ?assign? means to delegate address space to an ISP or End User for specific use within the Internet infrastructure they operate. Assignments must only be made for specific purposes documented by specific organisations and are not to be sub-assigned to other parties. > > Providing another entity with separate addresses (not prefixes) from a subnet used on a link operated by the assignment holder is not considered a sub-assignment. This includes for example letting visitors connect to the assignment holder's network, connecting a server or appliance to an assignment holder's network and setting up point-to-point links with 3rd parties. > > > 2.9. End Site > > An End Site is defined as an End User (subscriber) who has a business or legal relationship (same or associated entities) with a service provider that involves: > > ? that service provider assigning address space to the End User > > ? that service provider providing transit service for the End User to other sites > > ? that service provider carrying the End User's traffic > > ? that service provider advertising an aggregate prefix route that contains the End User's assignment > > > By these definitions, only an IR ("2.1. Internet Registry (IR)") can "assign" allocated address space to non-IRs, i. e. ISPs or End Users, in the context of ripe-707. > The term "ISP" is not wll defined within ripe-707 except for "LIRs are generally ISPs whose customers are primarily End Users and possibly other ISPs" in "2.4. Local Internet Registry (LIR)". The graph in "2. Definitions" suggests that ISPs are the entities that are actually creating the Internet, whereas (L)IRs are involved in distributing IP space only. Since, following 2.6., only an (I)SP _that also is an (L)IR_ could, acting in it's (L)IR role, "assign" address space, 2.9. should therefore receive a friendly "s/service provider/ISP/g" and have the first bullet point removed. > > On the other hand, 2.6. in it's current form ? except for the "separate addresses (not prefixes)" issue, as any singke address IS technically also a /128 prefix ? seems rather clear to me: if it's for the documented "specific use within the Internet infrastructure they operate", it's fine. Otherwise, a separate assignment is needed for either a new specific use _or a different End User_, so the ISP or End User (or the ISP for it's End User) will have to request that from an (L)IR (which it may be itself, if the ISP or End User is an LIR as well). > > Thus, if you need "multiple addresses" for your "physical server" and you received an assignment for your infrastructure including your server(s), I cannot see a conflict with ripe-707. If you want to add a dedicated server for a customer of yours, I'd expect you to get a new (non-PI) prefix (i. e. no less than a /64 as per 5.4.1.) for this different End User from your LIR of choice (or have that End User apply for a /48 PIv6 via your cooperative LIR). > > Regards, > -kai > > > ********************************************** > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Thu Jan 17 21:22:05 2019 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 17 Jan 2019 21:22:05 +0100 Subject: [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification In-Reply-To: <4a668701-e63a-8f34-2f37-df25ecc49bbf@uu.org> References: <7C952EEF-C67E-4A3A-962C-DD2B0DF06A24@consulintel.es> <2577d148-f96f-93cf-1b68-780d30fa742f@uu.org> <4a668701-e63a-8f34-2f37-df25ecc49bbf@uu.org> Message-ID: <3B0C9C22-977D-4082-ABDB-40E4306B152A@consulintel.es> ?Hi Kai, Actually, yes and not. I?m talking about the clarification of 2.6 in the scope of 7 (PI) not in the scope of PA. Regards, Jordi De: address-policy-wg en nombre de Kai 'wusel' Siering Organizaci?n: Unseen University, Department of Magic Mails Fecha: jueves, 17 de enero de 2019, 20:58 Para: Asunto: Re: [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification Hi Jordi, you're mixing things up. This is not about 2016-04, which was approved long time ago. This is about ripe-707 [1], titled "IPv6 Address Allocation and Assignment Policy" ? the current policy in question you want to be modified. Regards, -kai [1] https://www.ripe.net/publications/docs/ripe-707#assign Am 17.01.2019 um 20:34 schrieb JORDI PALET MARTINEZ: Hi Kai, You?re missing that 2016-04 is for the clarification of IPv6 PI, not PA. https://www.ripe.net/participate/policies/proposals/2016-04 Regards, Jordi De: address-policy-wg en nombre de Kai 'wusel' Siering Organizaci?n: Unseen University, Department of Magic Mails Fecha: jueves, 17 de enero de 2019, 20:16 Para: Asunto: Re: [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification On 17.01.2019 15:37, JORDI PALET MARTINEZ via address-policy-wg wrote: We need to consider as well, as I depicted already before, that if you have a physical sever, you probably need also multiple addresses for that server, that's why, I think the policy should allow that (this is clearly now allowed now). Let's consult ripe-707: 2.6. Assign To ?assign? means to delegate address space to an ISP or End User for specific use within the Internet infrastructure they operate. Assignments must only be made for specific purposes documented by specific organisations and are not to be sub-assigned to other parties. Providing another entity with separate addresses (not prefixes) from a subnet used on a link operated by the assignment holder is not considered a sub-assignment. This includes for example letting visitors connect to the assignment holder's network, connecting a server or appliance to an assignment holder's network and setting up point-to-point links with 3rd parties. 2.9. End Site An End Site is defined as an End User (subscriber) who has a business or legal relationship (same or associated entities) with a service provider that involves: ? that service provider assigning address space to the End User ? that service provider providing transit service for the End User to other sites ? that service provider carrying the End User's traffic ? that service provider advertising an aggregate prefix route that contains the End User's assignment By these definitions, only an IR ("2.1. Internet Registry (IR)") can "assign" allocated address space to non-IRs, i. e. ISPs or End Users, in the context of ripe-707. The term "ISP" is not wll defined within ripe-707 except for "LIRs are generally ISPs whose customers are primarily End Users and possibly other ISPs" in "2.4. Local Internet Registry (LIR)". The graph in "2. Definitions" suggests that ISPs are the entities that are actually creating the Internet, whereas (L)IRs are involved in distributing IP space only. Since, following 2.6., only an (I)SP _that also is an (L)IR_ could, acting in it's (L)IR role, "assign" address space, 2.9. should therefore receive a friendly "s/service provider/ISP/g" and have the first bullet point removed. On the other hand, 2.6. in it's current form ? except for the "separate addresses (not prefixes)" issue, as any singke address IS technically also a /128 prefix ? seems rather clear to me: if it's for the documented "specific use within the Internet infrastructure they operate", it's fine. Otherwise, a separate assignment is needed for either a new specific use _or a different End User_, so the ISP or End User (or the ISP for it's End User) will have to request that from an (L)IR (which it may be itself, if the ISP or End User is an LIR as well). Thus, if you need "multiple addresses" for your "physical server" and you received an assignment for your infrastructure including your server(s), I cannot see a conflict with ripe-707. If you want to add a dedicated server for a customer of yours, I'd expect you to get a new (non-PI) prefix (i. e. no less than a /64 as per 5.4.1.) for this different End User from your LIR of choice (or have that End User apply for a /48 PIv6 via your cooperative LIR). Regards, -kai ********************************************** 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wusel+ml at uu.org Thu Jan 17 23:59:39 2019 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Thu, 17 Jan 2019 23:59:39 +0100 Subject: [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification In-Reply-To: <3B0C9C22-977D-4082-ABDB-40E4306B152A@consulintel.es> References: <7C952EEF-C67E-4A3A-962C-DD2B0DF06A24@consulintel.es> <2577d148-f96f-93cf-1b68-780d30fa742f@uu.org> <4a668701-e63a-8f34-2f37-df25ecc49bbf@uu.org> <3B0C9C22-977D-4082-ABDB-40E4306B152A@consulintel.es> Message-ID: Hi Jordi, well, doesn't say so in the subject line, and cannot be done anyway: there is no difference between "to assign" and "to assign". 2.6 (was and) is a definition valid for any IPv6 assignment, be it PI, IXP, Anycast, whatever. So you're aiming at a definition like: > > 2.6. Assign > > To ?assign? means to delegate address space to an ISP or End User for specific use within the Internet infrastructure they operate, if it's Provider Independent IPv6 adress space. In case it's not Provider Independent IPv6 address space, and not IPv6 adress space for authoritative TLD or ENUM Tier 0/1 DNS lookup services either, to ?assign? means to delegate address space to an End User, of the LIR as an ISP or a of an subordinate ISP, for [?]. If the IPv6 address space in question is for authoritative TLD or ENUM Tier 0/1 DNS lookup services, to ?assign? means [?]. IMO that's not going to fly. Furthermore, what needs to be "clarified" about "Assignments [?] are not to be sub-assigned to other parties"? They. Are. Not. Any, ever. PIv6 even doubly not (7.). How to put this more "clearly"? From the text of ripe-707, there is a rather clear definition what "making an assignment" is about (and what isn't) ? if this is not how this working group expects the RIPE NCC to understand the policy text, then, and only then, the text needs to be modified. Currently I see no motion to lift the "no sub-assignment, period" clause, though. How the RIPE NCC understands the, now current, policy text has been pointed out as part of 2016-04 [1] ("A. RIPE NCC's Understanding of the Proposed Policy"). That "understanding" to me is "good enough" with regard to what 2.6 currently reads. Please re-read that clarification, it's important ? obviously you _still_ missed that there is no difference between PIv6 and non-PIv6 in terms of (sub-) assignment. That suggests that, if you're an LIR, an ISP, or an End User, you're probably not assigning/using assigned address space as per policy. That said: what you are aiming at is *not* a "clarification" of what a (sub-) assignment is (and any sub-assignment still is an assignment and therefore falls under the definition per 2.6.). You are looking for extending the allowed use-cases of PIv6. Please keep in mind, though, that anything that could count as a sub-assingment would be still be forbidden by the Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region [2], so the only way forward is to extend the examples in the second paragraph of 2.6 ? the one 2016-04 brought us. But why do you want to extend the allowed use cases for PIv6? To me, the general idea that PI space should be for End Users, and End Users only (be them companies, ISPs, or simply people), for their own use, still makes sense, as well as this rationale from [2]: > Some ISPs prefer to receive Internet number resources as an End User rather than becoming an LIR even though they provide services to their own customers and therefore sub-assign address space assigned by the RIPE NCC. Such End User ISPs often receive several separate PI prefixes as this can be a cheaper alternative for them. Sub-assignment of PI address space in this manner is in contravention of the RIPE policies concerning direct resource assignment policies. It is also detrimental to aggregation of routing prefixes in the global routing tables. And, with the ? odd interpretation ? letting friends & family access one's WiFi via IPv6 constitutes the act of sub-assignment ? out of the way, IPv6 is properly usable again, PI or not. Regards, -kai [1] https://www.ripe.net/participate/policies/proposals/2016-04 [2] http://www.ripe.net/ripe/docs/contract-req Am 17.01.2019 um 21:22 schrieb JORDI PALET MARTINEZ: > > ?Hi Kai, > > > > Actually, yes and not. > > > > I?m talking about the clarification of 2.6 in the scope of 7 (PI) not in the scope of PA. > > > Regards, > > Jordi > > > > > > > > *De: *address-policy-wg en nombre de Kai 'wusel' Siering > *Organizaci?n: *Unseen University, Department of Magic Mails > *Fecha: *jueves, 17 de enero de 2019, 20:58 > *Para: * > *Asunto: *Re: [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification > > > > Hi Jordi, > > you're mixing things up. This is not about 2016-04, which was approved long time ago. This is about ripe-707 [1], titled "IPv6 Address Allocation and Assignment Policy" ? the current policy in question you want to be modified. > > Regards, > -kai > > > [1] https://www.ripe.net/publications/docs/ripe-707#assign > > Am 17.01.2019 um 20:34 schrieb JORDI PALET MARTINEZ: > > Hi Kai, > > > > You?re missing that 2016-04 is for the clarification of IPv6 PI, not PA. > > > > https://www.ripe.net/participate/policies/proposals/2016-04 > > > Regards, > > Jordi > > > > > > > > *De: *address-policy-wg en nombre de Kai 'wusel' Siering > *Organizaci?n: *Unseen University, Department of Magic Mails > *Fecha: *jueves, 17 de enero de 2019, 20:16 > *Para: * > *Asunto: *Re: [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification > > > > On 17.01.2019 15:37, JORDI PALET MARTINEZ via address-policy-wg wrote: > > We need to consider as well, as I depicted already before, that if you have a physical sever, you probably need also multiple addresses for that server, that's why, I think the policy should allow that (this is clearly now allowed now). > > > Let's consult ripe-707: > > > > 2.6. Assign > > To ?assign? means to delegate address space to an ISP or End User for specific use within the Internet infrastructure they operate. Assignments must only be made for specific purposes documented by specific organisations and are not to be sub-assigned to other parties. > > Providing another entity with separate addresses (not prefixes) from a subnet used on a link operated by the assignment holder is not considered a sub-assignment. This includes for example letting visitors connect to the assignment holder's network, connecting a server or appliance to an assignment holder's network and setting up point-to-point links with 3rd parties. > > > 2.9. End Site > > An End Site is defined as an End User (subscriber) who has a business or legal relationship (same or associated entities) with a service provider that involves: > > ? that service provider assigning address space to the End User > > ? that service provider providing transit service for the End User to other sites > > ? that service provider carrying the End User's traffic > > ? that service provider advertising an aggregate prefix route that contains the End User's assignment > > > By these definitions, only an IR ("2.1. Internet Registry (IR)") can "assign" allocated address space to non-IRs, i. e. ISPs or End Users, in the context of ripe-707. > The term "ISP" is not wll defined within ripe-707 except for "LIRs are generally ISPs whose customers are primarily End Users and possibly other ISPs" in "2.4. Local Internet Registry (LIR)". The graph in "2. Definitions" suggests that ISPs are the entities that are actually creating the Internet, whereas (L)IRs are involved in distributing IP space only. Since, following 2.6., only an (I)SP _that also is an (L)IR_ could, acting in it's (L)IR role, "assign" address space, 2.9. should therefore receive a friendly "s/service provider/ISP/g" and have the first bullet point removed. > > On the other hand, 2.6. in it's current form ? except for the "separate addresses (not prefixes)" issue, as any singke address IS technically also a /128 prefix ? seems rather clear to me: if it's for the documented "specific use within the Internet infrastructure they operate", it's fine. Otherwise, a separate assignment is needed for either a new specific use _or a different End User_, so the ISP or End User (or the ISP for it's End User) will have to request that from an (L)IR (which it may be itself, if the ISP or End User is an LIR as well). > > Thus, if you need "multiple addresses" for your "physical server" and you received an assignment for your infrastructure including your server(s), I cannot see a conflict with ripe-707. If you want to add a dedicated server for a customer of yours, I'd expect you to get a new (non-PI) prefix (i. e. no less than a /64 as per 5.4.1.) for this different End User from your LIR of choice (or have that End User apply for a /48 PIv6 via your cooperative LIR). > > Regards, > -kai > > > > ********************************************** > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschmidt at ripe.net Fri Jan 18 11:51:49 2019 From: mschmidt at ripe.net (Marco Schmidt) Date: Fri, 18 Jan 2019 11:51:49 +0100 Subject: [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification In-Reply-To: References: <7C952EEF-C67E-4A3A-962C-DD2B0DF06A24@consulintel.es> <2577d148-f96f-93cf-1b68-780d30fa742f@uu.org> Message-ID: Hello Jordi and all, Allow me to provide some clarification. While 2016-04 was indeed focused primarily on IPv6 PI assignments, the adjusted definition in section 2.6 applies to all assignments. The RIPE NCC Impact Analysis says: ------------- This definition of sub-assignments will apply for assignments within IPv6 allocations and for IPv6 Provider Independent (PI) Assignments. While LIRs have to consider this definition when providing assignments, the RIPE NCC will apply this understanding during the evaluation of IPv6 PI requests and when reviewing assignments within allocations during a potential audit of an LIR. ------------ https://www.ripe.net/participate/policies/proposals/2016-04 Kind regards, Marco Schmidt Policy Officer RIPE NCC On 17/01/2019 20:34, JORDI PALET MARTINEZ via address-policy-wg wrote: > > Hi Kai, > > You?re missing that 2016-04 is for the clarification of IPv6 PI, not PA. > > https://www.ripe.net/participate/policies/proposals/2016-04 > > > Regards, > > Jordi > > *De: *address-policy-wg en nombre > de Kai 'wusel' Siering > *Organizaci?n: *Unseen University, Department of Magic Mails > *Fecha: *jueves, 17 de enero de 2019, 20:16 > *Para: * > *Asunto: *Re: [address-policy-wg] suggestions from the list about IPv6 > sub-assignment clarification > > On 17.01.2019 15:37, JORDI PALET MARTINEZ via address-policy-wg wrote: > > We need to consider as well, as I depicted already before, that if you have a physical sever, you probably need also multiple addresses for that server, that's why, I think the policy should allow that (this is clearly now allowed now). > > > Let's consult ripe-707: > > > 2.6. Assign > > To ?assign? means to delegate address space to an ISP or End User > for specific use within the Internet infrastructure they operate. > Assignments must only be made for specific purposes documented by > specific organisations and are not to be sub-assigned to other > parties. > > Providing another entity with separate addresses (not prefixes) > from a subnet used on a link operated by the assignment holder is > not considered a sub-assignment. This includes for example letting > visitors connect to the assignment holder's network, connecting a > server or appliance to an assignment holder's network and setting > up point-to-point links with 3rd parties. > > > 2.9. End Site > > An End Site is defined as an End User (subscriber) who has a > business or legal relationship (same or associated entities) with > a service provider that involves: > > ?that service provider assigning address space to the End User > > ?that service provider providing transit service for the End User > to other sites > > ?that service provider carrying the End User's traffic > > ?that service provider advertising an aggregate prefix route that > contains the End User's assignment > > > By these definitions, only an IR ("2.1. Internet Registry (IR)")? can > "assign" allocated address space to non-IRs, i. e. ISPs or End Users, > in the context of ripe-707. > The term "ISP" is not wll defined within ripe-707 except for "LIRs are > generally ISPs whose customers are primarily End Users and possibly > other ISPs" in "2.4. Local Internet Registry (LIR)". The graph in "2. > Definitions" suggests that ISPs are the entities that are actually > creating the Internet, whereas (L)IRs are involved in distributing IP > space only. Since, following 2.6., only an (I)SP _that also is an > (L)IR_ could, acting in it's (L)IR role, "assign" address space, 2.9. > should therefore receive a friendly "s/service provider/ISP/g" and > have the first bullet point removed. > > On the other hand, 2.6. in it's current form ? except for the > "separate addresses (not prefixes)" issue, as any singke address IS > technically also a /128 prefix ? seems rather clear to me: if it's for > the documented "specific use within the Internet infrastructure they > operate", it's fine. Otherwise, a separate assignment is needed for > either a new specific use _or a different End User_, so the ISP or End > User (or the ISP for it's End User) will have to request that from an > (L)IR (which it may be itself, if the ISP or End User is an LIR as well). > > Thus, if you need "multiple addresses" for your "physical server" and > you received an assignment for your infrastructure including your > server(s), I cannot see a conflict with ripe-707. If you want to add a > dedicated server for a customer of yours, I'd expect you to get a new > (non-PI) prefix (i. e. no less than a /64 as per 5.4.1.) for this > different End User from your LIR of choice (or have that End User > apply for a /48 PIv6 via your cooperative LIR). > > Regards, > -kai > > > ********************************************** > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Sun Jan 20 17:35:28 2019 From: gert at space.net (Gert Doering) Date: Sun, 20 Jan 2019 17:35:28 +0100 Subject: [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification In-Reply-To: References: <7C952EEF-C67E-4A3A-962C-DD2B0DF06A24@consulintel.es> <2577d148-f96f-93cf-1b68-780d30fa742f@uu.org> <4a668701-e63a-8f34-2f37-df25ecc49bbf@uu.org> <3B0C9C22-977D-4082-ABDB-40E4306B152A@consulintel.es> Message-ID: <20190120163528.GE1543@Space.Net> Hi, On Thu, Jan 17, 2019 at 11:59:39PM +0100, Kai 'wusel' Siering wrote: > well, doesn't say so in the subject line, and cannot be done > anyway: there is no difference between "to assign" and "to assign". > 2.6 (was and) is a definition valid for any IPv6 assignment, be it > PI, IXP, Anycast, whatever. Well, strictly speaking, a new version of Jordi's 2018-02 *could* change terminology to avoid using the term "(sub-)assignment" for the IPv6 PI case, and just describe what the holder is allowed/expected to do with it. OTOH: > How the RIPE NCC understands the, now current, policy text has been pointed out as part of 2016-04 [1] ("A. RIPE NCC's Understanding of the Proposed Policy"). That "understanding" to me is "good enough" with regard to what 2.6 currently reads. Please re-read that clarification, it's important ??? obviously you _still_ missed that there is no difference between PIv6 and non-PIv6 in terms of (sub-) assignment. That suggests that, if you're an LIR, an ISP, or an End User, you're probably not assigning/using assigned address space as per policy. ... this is a fairly clear "the current policy text is good enough" statement to me... :-) So, before going off into "oh, nice idea how to change the wording!" land, let's hear more voices on whether people here in the WG actually see the need for change... 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From martin.tonusoo at citictel-cpc.com Thu Jan 24 08:35:00 2019 From: martin.tonusoo at citictel-cpc.com (Martin Tonusoo) Date: Thu, 24 Jan 2019 15:35:00 +0800 (HKT) Subject: [address-policy-wg] 2019-01 New Policy Proposal (Clarification of Definition for "ASSIGNED PA") In-Reply-To: <4dd3fbae-6e64-ccad-2c41-62a7ef392394@ripe.net> References: <4dd3fbae-6e64-ccad-2c41-62a7ef392394@ripe.net> Message-ID: <456844002.127922.1548315300501.JavaMail.zimbra@citictel-cpc.com> 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 -------------------------- Direct: +372 622 3321 NOC 24/7: +372 622 3300 NOC 24/7: +7 495 9815670 From: "Marco Schmidt" To: "address-policy-wg" 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 before 15 February 2019. Regards, Marco Schmidt Policy Officer RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominik at clouvider.co.uk Thu Jan 24 10:35:43 2019 From: dominik at clouvider.co.uk (Dominik Nowacki) Date: Thu, 24 Jan 2019 09:35:43 +0000 Subject: [address-policy-wg] 2019-01 New Policy Proposal (Clarification of Definition for "ASSIGNED PA") In-Reply-To: <456844002.127922.1548315300501.JavaMail.zimbra@citictel-cpc.com> References: <4dd3fbae-6e64-ccad-2c41-62a7ef392394@ripe.net>, <456844002.127922.1548315300501.JavaMail.zimbra@citictel-cpc.com> Message-ID: 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. Registered office: 88 Wood Street, London, United Kingdom, EC2V 7RS. On 24 Jan 2019, at 07:35, Martin Tonusoo > 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 -------------------------- Direct: +372 622 3321 NOC 24/7: +372 622 3300 NOC 24/7: +7 495 9815670 ________________________________ From: "Marco Schmidt" > To: "address-policy-wg" > 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 > before 15 February 2019. Regards, Marco Schmidt Policy Officer RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From anw at artfiles.de Mon Jan 28 12:07:17 2019 From: anw at artfiles.de (Andreas Worbs) Date: Mon, 28 Jan 2019 12:07:17 +0100 Subject: [address-policy-wg] 2019-01 New Policy Proposal (Clarification of Definition for "ASSIGNED PA") In-Reply-To: References: <4dd3fbae-6e64-ccad-2c41-62a7ef392394@ripe.net> <456844002.127922.1548315300501.JavaMail.zimbra@citictel-cpc.com> Message-ID: <7192043c-33f4-9a55-42df-ceb95ea82c06@artfiles.de> +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_ . Registered > office:?_88 Wood Street, London, United Kingdom, EC2V 7RS_.? > > On 24 Jan 2019, at 07:35, Martin Tonusoo > > 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 >> -------------------------- >> Direct: +372 622 3321 >> NOC 24/7: +372 622 3300 >> NOC 24/7: +7 495 9815670 >> >> >> ------------------------------------------------------------------------ >> *From: *"Marco Schmidt" > >> *To: *"address-policy-wg" > > >> *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 >> > >> 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 at artfiles.de | Web: http://www.artfiles.de Gesch?ftsf?hrer: Harald Oltmanns | Tim Evers Eingetragen im Handelsregister Hamburg - HRB 81478 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x8E0F20B93EC99081.asc Type: application/pgp-keys Size: 3086 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From Olaf.Sonderegger at abraxas.ch Tue Jan 29 12:49:52 2019 From: Olaf.Sonderegger at abraxas.ch (Sonderegger Olaf ABRAXAS) Date: Tue, 29 Jan 2019 11:49:52 +0000 Subject: [address-policy-wg] 2019-01 New Policy Proposal (Clarification of Definition for "ASSIGNED PA") Message-ID: 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 at abraxas.ch | www.abraxas.ch ---------------------------------------------------------------- Date: Mon, 28 Jan 2019 12:07:17 +0100 From: Andreas Worbs To: address-policy-wg at 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 at 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_ . Registered > office:?_88 Wood Street, London, United Kingdom, EC2V 7RS_.? > > On 24 Jan 2019, at 07:35, Martin Tonusoo > > 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 >> -------------------------- >> Direct: +372 622 3321 >> NOC 24/7: +372 622 3300 >> NOC 24/7: +7 495 9815670 >> >> >> --------------------------------------------------------------------- >> --- >> *From: *"Marco Schmidt" > > >> *To: *"address-policy-wg" > > >> *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 >> > >> 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 at artfiles.de | Web: http://www.artfiles.de Gesch?ftsf?hrer: Harald Oltmanns | Tim Evers Eingetragen im Handelsregister Hamburg - HRB 81478 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5115 bytes Desc: not available URL: