[address-policy-wg] 2018-02 New Policy Proposal (Assignment Clarification in IPv6 Policy)

Hi Kai,

 

Responses below, in-line.


Regards,

Jordi

 

 

De: address-policy-wg <address-policy-wg-bounces at ripe.net> en nombre de Kai 'wusel' Siering <wusel+ml at uu.org>
Organización: Unseen University, Department of Magic Mails
Fecha: martes, 17 de abril de 2018, 23:24
Para: <address-policy-wg at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20180418/5e783e03/attachment.html>