By the way, forgot something ... I've created an "online diff" so you can compare the actual text, with my proposal: https://www.diffchecker.com/SMXYO2rc Regards, Jordi -----Mensaje original----- De: address-policy-wg <address-policy-wg-bounces@ripe.net> en nombre de JORDI PALET MARTINEZ via address-policy-wg <address-policy-wg@ripe.net> Responder a: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Fecha: martes, 17 de abril de 2018, 16:52 Para: <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] 2018-02 New Policy Proposal (Assignment Clarification in IPv6 Policy) Hi all, As you probably remember, during the discussion of the recently implemented 2016-04, I complained that we should not approve a policy proposal with a wording that creates (in my opinion), discrepancies between the NCC impact analysis and the policy text. I was suggested that it can always be improved ... so that's what I'm doing here. I've also suggested the same text in the other 4 RIRs with equivalent policy proposal, because all them have the same problem. The main point is to clarify the actual interpretation to make clear that it is allowed from up to a single /64, to use non-permanently, any number of addresses (not just a single one). So basically, what I'm saying is: 1) Is not a sub-assignment a point-to-point (maximum a /64) even if this is permanent. However, the point-to-point can't be used as permanent addressing for "actual" transit (so you can't use the point-to-point addressing and then makeup an IPv6 NAT/NPT, or something similar for devices behind it). 2) Is not a sub-assignment up to a /64 if non-permanent. Example a device in a hot-spot, with use multiple addresses (example, VMs) from a single /64, or the same situation if an employee brings any kind of device to the enterprise WiFi or wired network. This means that I'm excluding the case of a data center allocating *permanent* /64 to server interfaces (non-permanent will be ok). Remember that this is for PI, and my personal opinion on this is that, a datacenter, should be an LIR, so using PA. This is an open question here, and I may be wrong. So, what do you think on the overall proposal and specially in this last point (data center can be PI and then we should have a more complex text that allows that case)? Thanks! Regards, Jordi -----Mensaje original----- De: address-policy-wg <address-policy-wg-bounces@ripe.net> en nombre de Marco Schmidt <mschmidt@ripe.net> Fecha: martes, 17 de abril de 2018, 15:55 Para: <address-policy-wg@ripe.net> Asunto: [address-policy-wg] 2018-02 New Policy Proposal (Assignment Clarification in IPv6 Policy) Dear colleagues, A new RIPE Policy proposal, 2018-02, "Assignment Clarification in IPv6 Policy" is now available for discussion. This proposal aims to clarify the definition of “Assign” in ripe-699 (section 2.6). The non-permanent provision of up to a /64 prefix to third parties shall not be considered a sub-assignment. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2018-02 As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal. We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 15 May 2018. Regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

Hi Sascha, I see your point on the last sentence. The idea of that is avoiding someone to have the bright idea to use the point-to-point links to offer permanent service by means of "IPv6 NAT/NPT". Maybe the wording is not the best. I just figured out an alternative one: "The addressing of the point-to-point link can be permanent; however, it can't be used as an artifact to avoid provisioning IPv6 addresses to circumvent this policy." May be the NCC can check if this make sense in english, or someone else can provide some other suggestions about how to say it, withou explicit mention to "IPv6 NAT/NPT" (which are just examples, as we could though in any way of "proxying", etc., and we prefer to avoid mentioning what technology ...). Regards, Jordi -----Mensaje original----- De: address-policy-wg <address-policy-wg-bounces@ripe.net> en nombre de "Sascha Luck [ml]" <apwg@c4inet.net> Fecha: martes, 17 de abril de 2018, 18:53 Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> CC: <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] 2018-02 New Policy Proposal (Assignment Clarification in IPv6 Policy) Hi Jordi, On Tue, Apr 17, 2018 at 04:57:20PM +0200, JORDI PALET MARTINEZ via address-policy-wg wrote: >I've created an "online diff" so you can compare the actual text, with my proposal: > >https://www.diffchecker.com/SMXYO2rc I have several issues with the proposal: 1) It perpetuates what may have been a good idea in 1990, viz the PI/PA distinction, into IPv6. IMO it's long past time to stop having special classes of addresses and to treat them as what they are, numbers. 2) It looks a lot like micro-management, trying to make policy for every edge case. Having said that, it seems to be necessary as the NCC is using an unreasonable interpretation of existing policy. 3) the last sentence of the policy text: "Only the addressing of the point-to-point link itself can be permanent and that addressing can't be used (neither directly or indirectly) for the actual communication." makes neither grammatical nor technical sense. for one thing, it's always "either/or" or "neither/nor" and neither/nor mustn't be used after a preceding negative ("can't"). For the other, if this point-to-point assignment can't even *indirectly* be used for communication, it can't be used for *anything* as traffic from the downstream /64 would surely be routed via the point-to-point link, thus using its addresses... That said, I'd see no reason not to support the proposal *if* that last sentence is removed (it's unneccessarily specific and technically prohibitive) Kind Regards, Sascha Luck > > >Regards, >Jordi > > >-----Mensaje original----- >De: address-policy-wg <address-policy-wg-bounces@ripe.net> en nombre de JORDI PALET MARTINEZ via address-policy-wg <address-policy-wg@ripe.net> >Responder a: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> >Fecha: martes, 17 de abril de 2018, 16:52 >Para: <address-policy-wg@ripe.net> >Asunto: Re: [address-policy-wg] 2018-02 New Policy Proposal (Assignment Clarification in IPv6 Policy) > > Hi all, > > As you probably remember, during the discussion of the recently implemented 2016-04, I complained that we should not approve a policy proposal with a wording that creates (in my opinion), discrepancies between the NCC impact analysis and the policy text. > > I was suggested that it can always be improved ... so that's what I'm doing here. > > I've also suggested the same text in the other 4 RIRs with equivalent policy proposal, because all them have the same problem. > > The main point is to clarify the actual interpretation to make clear that it is allowed from up to a single /64, to use non-permanently, any number of addresses (not just a single one). > > So basically, what I'm saying is: > 1) Is not a sub-assignment a point-to-point (maximum a /64) even if this is permanent. However, the point-to-point can't be used as permanent addressing for "actual" transit (so you can't use the point-to-point addressing and then makeup an IPv6 NAT/NPT, or something similar for devices behind it). > 2) Is not a sub-assignment up to a /64 if non-permanent. Example a device in a hot-spot, with use multiple addresses (example, VMs) from a single /64, or the same situation if an employee brings any kind of device to the enterprise WiFi or wired network. > > This means that I'm excluding the case of a data center allocating *permanent* /64 to server interfaces (non-permanent will be ok). Remember that this is for PI, and my personal opinion on this is that, a datacenter, should be an LIR, so using PA. > > This is an open question here, and I may be wrong. > > So, what do you think on the overall proposal and specially in this last point (data center can be PI and then we should have a more complex text that allows that case)? > > Thanks! > > Regards, > Jordi > > > -----Mensaje original----- > De: address-policy-wg <address-policy-wg-bounces@ripe.net> en nombre de Marco Schmidt <mschmidt@ripe.net> > Fecha: martes, 17 de abril de 2018, 15:55 > Para: <address-policy-wg@ripe.net> > Asunto: [address-policy-wg] 2018-02 New Policy Proposal (Assignment Clarification in IPv6 Policy) > > Dear colleagues, > > A new RIPE Policy proposal, 2018-02, "Assignment Clarification in IPv6 Policy" is now available for discussion. > > This proposal aims to clarify the definition of ╲Assign╡ in ripe-699 (section 2.6). The non-permanent provision of up to a /64 prefix to third parties shall not be considered a sub-assignment. > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2018-02 > > As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase is to discuss the proposal and provide feedback to the proposer. > > At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal. > > We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 15 May 2018. > > Regards, > > Marco Schmidt > Policy Officer > RIPE NCC > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > > > > > >********************************************** >IPv4 is over >Are you ready for the new Internet ? >http://www.consulintel.es >The IPv6 Company > >This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

Hi Max, Thanks for the (quick) inputs! To be honest, I was not sure that you also need that for your own case (or if you know other cases that need that). I really think if you are a hosting/housing provider for third companies, you should become an LIR, but as said, this is only my personal view. Let's see what others believe. By the way, it will be interesting to compare this with IPv4. Do we allow this case in IPv4? Or we need also a policy proposal to amend that? Regards, Jordi -----Mensaje original----- De: address-policy-wg <address-policy-wg-bounces@ripe.net> en nombre de Maximilian Wilhelm <max@rfc2324.org> Fecha: martes, 17 de abril de 2018, 17:14 Para: <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] 2018-02 New Policy Proposal (Assignment Clarification in IPv6 Policy) Anno domini 2018 JORDI PALET MARTINEZ via address-policy-wg scripsit: Hi, > As you probably remember, during the discussion of the recently implemented 2016-04, I complained that we should not approve a policy proposal with a wording that creates (in my opinion), discrepancies between the NCC impact analysis and the policy text. > > I was suggested that it can always be improved ... so that's what I'm doing here. > > I've also suggested the same text in the other 4 RIRs with equivalent policy proposal, because all them have the same problem. > > The main point is to clarify the actual interpretation to make clear that it is allowed from up to a single /64, to use non-permanently, any number of addresses (not just a single one). > > So basically, what I'm saying is: > 1) Is not a sub-assignment a point-to-point (maximum a /64) even if this is permanent. However, the point-to-point can't be used as permanent addressing for "actual" transit (so you can't use the point-to-point addressing and then makeup an IPv6 NAT/NPT, or something similar for devices behind it). > 2) Is not a sub-assignment up to a /64 if non-permanent. Example a device in a hot-spot, with use multiple addresses (example, VMs) from a single /64, or the same situation if an employee brings any kind of device to the enterprise WiFi or wired network. > > This means that I'm excluding the case of a data center allocating *permanent* /64 to server interfaces (non-permanent will be ok). Remember that this is for PI, and my personal opinion on this is that, a datacenter, should be an LIR, so using PA. > > This is an open question here, and I may be wrong. > > So, what do you think on the overall proposal and specially in this last point (data center can be PI and then we should have a more complex text that allows that case)? I like the overall thing, but I don't like the DC part (as you might have guessed :)). My approach deliberately included housing/hosting as you can read in the rationale and this is something I would like to keep included for small hosters. I think the argument of scale applies here. Having only a /48 for your DC including your own infrastructure and some customer stuff won't get you far (if you don't ignore RFCs and BCPs). So for me this would be fine. If you grow, become an LIR, get a /29, be happy, everyone is happy. Best Max -- The real problem with C++ for kernel modules is: the language just sucks. -- Linus Torvalds ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

Hi Kai, Responses below, in-line. 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: martes, 17 de abril de 2018, 23:24 Para: <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] 2018-02 New Policy Proposal (Assignment Clarification in IPv6 Policy) Moin, am 17.04.2018 um 16:51 schrieb JORDI PALET MARTINEZ via address-policy-wg: I've also suggested the same text in the other 4 RIRs with equivalent policy proposal, because all them have the same problem.

From my point of view, if there's a policy that's sound and valid for other RIRs, they will adopt it over time. IF they struggle with similar issues (which I frankly don't know).

Yes, I can confirm that in the other RIRs policy there is the same sub-assignment text as we initially had, so same issues. The main point is to clarify the actual interpretation to make clear that it is allowed from up to a single /64, to use non-permanently, any number of addresses (not just a single one). Above all, what exactly is unclear in "the actual interpretation" done by whom? If you followed the previous discussion it was clear that actual policy text talks about a single address, but then the talks about /64 … 2) Is not a sub-assignment up to a /64 if non-permanent. Example a device in a hot-spot, with use multiple addresses (example, VMs) from a single /64, or the same situation if an employee brings any kind of device to the enterprise WiFi or wired network. With "in a hot-spot" you refer to WiFi? The "assignment" of a specific prefix for a specific WiFi in all practical setups will be a permanent one — no-one rotates the /64s on their WiFi APs every other week or even year. So, as we're on a clarifying mission, what constitutes a) a "permanent" and b) a "[sub-] assignment"? You’re confused here I think. We are talking about the address that get the customer of the hotspot, so what you get when you connect to that WiFi accesspoint. The access point may get a single /64 or may be is a router and is getting /56 so it has many /64s available to provisioning to each “customers” as per RFC8273 (for example). ripe-699 tried to ensure that RIPE NCC does not "misinterpret" third parties getting leases (or, in the SLAAC case, just grabbing the MAC-based address) from a PI assignment as a "[sub-] assignment" of said address space. If the changed text actually will work as intended is yet to be seen — why the rush to change the policy text _again_?! Because I don’t think it was a good change and I’d the option to appeal that or start a new proposal improving it. It's my strong believe that adding more wording about what use isn't considered as a "[sub-] assignment" will only lead to more edge cases and more vague applications. I think in the other way around, we are making it clearer. This means that I'm excluding the case of a data center allocating *permanent* /64 to server interfaces (non-permanent will be ok). Remember that I'm not a datacenter, but I run stuff in datacenters. Are you intending to forbid this use case? Are you actively trying to make PIv6 go away completely by disallowing any practical use? No, this is not my intent. I’m asking the WG what they think on this (and I stated that my view may be wrong). this is for PI, and my personal opinion on this is that, a datacenter, should be an LIR, so using PA. A datacenter is a datacenter, an ISP is an ISP, and an End User is an End User; none of these are forced to become a LIR. Actually, PI, Provider Independent address space, can make much sense for an independent datacenter operator to run their infrastructure with — as well as for an ambitious End User. Let’s see if the WG has that view as well. This is why I’m asking. If an End User becomes an ISP, they still may use their PI address space for their infrastructure. The same applies to an End User or ISP who becomes a LIR ... Please remember: »LIRs are generally ISPs whose customers are primarily End Users and possibly other ISPs.« It's not: »Any ISP must be a LIR in order to assign address space to their end users.« It's neither: »Anyone in need of IPv6 address space must become an LIR.« But let's review the suggested new policy text: »[…] The fact that a unique address or even a unique /64 prefix is non-permanently provided to third parties, on a link operated by the original receiver of the assignment, shall not be considered a sub-assignment.« So, if I, as the assignment holder of PIv6 space, allocate a /64 for any of my family member's devices (e. g. a /64 for my gear, a /64 for my wife's and each kid's devices) for accountability (that is: legal) reasons, that's sub-assigning (again)? After all, it's my infra they use. With previous policy that was not possible. With actual policy if it is a single address is possible. With my proposal, /64 is possible. Is a tunnel over my DSL line to a friend a »link operated« by me or my friend or my or his access provider? We would use <assigned-prefix>:<day>::/64 for it, so it's definately not »permanently provided«. There always ways to trick every policy, you don’t think so? »This includes, for example, guests or employees (devices or servers), hotspots, and point-to-point links or VPNs.« VPN- and P2P-links are usually configured via static, hence »permanent«, addresses, this contradicts what was stated before. I don’t think so, typically VPNs you have a pool of addresses for “all the VPN customers”. It can be the other way around, and of course it can be an “always-on” VPN. For me that is a point-to-point actually (it is a permanent link). »The provision of addressing for permanent connectivity or broadband services is still considered a sub-assignment. Only the addressing of the point-to-point link itself can be permanent and that addressing can't be used (neither directly or indirectly) for the actual communication.« How is traffic going over »the point-to-point link« (which, actually?) not »indirectly« making use of the »addressing« of that link »for the actual communication«? Without addresses, there would be no link, would there? As I said, the more fine-grained the policy text, the more issues you get, the less clear the policy becomes. Therefore I object this proposal. I suggested in a previous email a more open text, to avoid going into too much fine-grained text. I'm really puzzled why no-one is aiming to simply amend »7. IPv6 Provider Independent (PI) Assignments« by something along »PIv6 is not to be used as ›PA lite‹; use of PIv6 should be centered running assignment holder's infrastructure, not as a means to provide ISP services to end users.« To me, that's the bottom line regarding the intended use of PIv6 space. This was one of my first suggestions when Max started this work. Then I was convinced by the community that we should allow this … Regards, -kai FTR: https://www.ripe.net/participate/2016-04#impact-analysis gives an 404 in https://www.ripe.net/participate/policies/proposals/2018-02, proper link address seems to be https://www.ripe.net/participate/policies/proposals/2016-04#impact-analysis ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.