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. 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@ripe.net> en nombre de Jetten Raymond <raymond.jetten@elisa.fi> Fecha: jueves, 17 de enero de 2019, 14:03 Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> CC: "address-policy-wg@ripe.net" <address-policy-wg@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@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@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.
# commented -----Original Message----- From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Sent: 17. tammikuuta 2019 15:22 To: Jetten Raymond <raymond.jetten@elisa.fi> Cc: address-policy-wg@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 <address-policy-wg-bounces@ripe.net> en nombre de Jetten Raymond <raymond.jetten@elisa.fi> Fecha: jueves, 17 de enero de 2019, 14:03 Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> CC: "address-policy-wg@ripe.net" <address-policy-wg@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@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@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.
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 <address-policy-wg-bounces@ripe.net> en nombre de Jetten Raymond <raymond.jetten@elisa.fi> Fecha: jueves, 17 de enero de 2019, 14:41 Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> CC: "address-policy-wg@ripe.net" <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification # commented -----Original Message----- From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Sent: 17. tammikuuta 2019 15:22 To: Jetten Raymond <raymond.jetten@elisa.fi> Cc: address-policy-wg@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 <address-policy-wg-bounces@ripe.net> en nombre de Jetten Raymond <raymond.jetten@elisa.fi> Fecha: jueves, 17 de enero de 2019, 14:03 Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> CC: "address-policy-wg@ripe.net" <address-policy-wg@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@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@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. ********************************************** 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.
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
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 <address-policy-wg-bounces@ripe.net> en nombre de Kai 'wusel' Siering <wusel+ml@uu.org> Organización: Unseen University, Department of Magic Mails Fecha: jueves, 17 de enero de 2019, 20:16 Para: <address-policy-wg@ripe.net> 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.
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 <address-policy-wg-bounces@ripe.net> en nombre de Kai 'wusel' Siering <wusel+ml@uu.org> *Organización: *Unseen University, Department of Magic Mails *Fecha: *jueves, 17 de enero de 2019, 20:16 *Para: *<address-policy-wg@ripe.net> *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.
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 <address-policy-wg-bounces@ripe.net> en nombre de Kai 'wusel' Siering <wusel+ml@uu.org> Organización: Unseen University, Department of Magic Mails Fecha: jueves, 17 de enero de 2019, 20:58 Para: <address-policy-wg@ripe.net> 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 <address-policy-wg-bounces@ripe.net> en nombre de Kai 'wusel' Siering <wusel+ml@uu.org> Organización: Unseen University, Department of Magic Mails Fecha: jueves, 17 de enero de 2019, 20:16 Para: <address-policy-wg@ripe.net> 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.
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 <address-policy-wg-bounces@ripe.net> en nombre de Kai 'wusel' Siering <wusel+ml@uu.org> *Organización: *Unseen University, Department of Magic Mails *Fecha: *jueves, 17 de enero de 2019, 20:58 *Para: *<address-policy-wg@ripe.net> *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 <address-policy-wg-bounces@ripe.net> <mailto:address-policy-wg-bounces@ripe.net> en nombre de Kai 'wusel' Siering <wusel+ml@uu.org> <mailto:wusel+ml@uu.org> *Organización: *Unseen University, Department of Magic Mails *Fecha: *jueves, 17 de enero de 2019, 20:16 *Para: *<address-policy-wg@ripe.net> <mailto:address-policy-wg@ripe.net> *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.
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
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 <address-policy-wg-bounces@ripe.net> en nombre de Kai 'wusel' Siering <wusel+ml@uu.org> *Organización: *Unseen University, Department of Magic Mails *Fecha: *jueves, 17 de enero de 2019, 20:16 *Para: *<address-policy-wg@ripe.net> *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.
Am 17. Januar 2019 14:21:38 MEZ schrieb JORDI PALET MARTINEZ via address-policy-wg <address-policy-wg@ripe.net>:
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
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 <address-policy-wg-bounces@ripe.net> en nombre de Kai 'wusel' Siering <wusel+ml@uu.org> Fecha: jueves, 17 de enero de 2019, 15:10 Para: JORDI PALET MARTINEZ via address-policy-wg <address-policy-wg@ripe.net> 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 <address-policy-wg@ripe.net>: >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.
participants (5)
-
Gert Doering -
Jetten Raymond -
JORDI PALET MARTINEZ -
Kai 'wusel' Siering -
Marco Schmidt