<html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">Moin, am 17.04.2018 um 16:51 schrieb JORDI PALET MARTINEZ via address-policy-wg: </div> <blockquote cite="mid:65A84868-F6CB-499B-ADAC-1EE3C6EA23F0@consulintel.es" type="cite"> <pre wrap="">I've also suggested the same text in the other 4 RIRs with equivalent policy proposal, because all them have the same problem.</pre> </blockquote> 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). <blockquote cite="mid:65A84868-F6CB-499B-ADAC-1EE3C6EA23F0@consulintel.es" type="cite"> <pre wrap="">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).</pre> </blockquote> Above all, what exactly is unclear in "the actual interpretation" done by whom? <blockquote cite="mid:65A84868-F6CB-499B-ADAC-1EE3C6EA23F0@consulintel.es" type="cite"> <pre wrap="">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.</pre> </blockquote> 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"? 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_?! 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. <blockquote cite="mid:65A84868-F6CB-499B-ADAC-1EE3C6EA23F0@consulintel.es" type="cite"> <pre wrap="">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 </pre> </blockquote> 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? <blockquote cite="mid:65A84868-F6CB-499B-ADAC-1EE3C6EA23F0@consulintel.es" type="cite"> <pre wrap="">this is for PI, and my personal opinion on this is that, a datacenter, should be an LIR, so using PA.</pre> </blockquote> 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. 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. 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«. »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. »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'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. Regards, -kai FTR: <a class="moz-txt-link-freetext" href="https://www.ripe.net/participate/2016-04#impact-analysis">https://www.ripe.net/participate/2016-04#impact-analysis</a> gives an 404 in <a class="moz-txt-link-freetext" href="https://www.ripe.net/participate/policies/proposals/2018-02">https://www.ripe.net/participate/policies/proposals/2018-02</a>, proper link address seems to be <a class="moz-txt-link-freetext" href="https://www.ripe.net/participate/policies/proposals/2016-04#impact-analysis">https://www.ripe.net/participate/policies/proposals/2016-04#impact-analysis</a> </body> </html>