[address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification)

Hi Sander,

> Yes, but the RIPE NCC checks your intended usage to confirm that it doesn't conflict with the policy.
>> BUT: how would the simple addition of »[w]ithin the context of these policies, a sub-assignment is an assignment of a length of /64 or shorter« will solve the issue that mentioning WiFi in the PI request leads to it's refusal? (Note that »no WiFi« is not even present on above's list.) 
> There are dozens (maybe hundreds) of ways in which to use address space. Those examples aren't meant to be exclusive. Now, the problem is that we never properly defined what a sub-assignment in this context is. Just based on the language, every case where I tell you to use an address is an assignment. If I were to give you a bit of paper that says "you can use 2001:db8::1" then that is an assignment. I just assigned 2001:db8::1 to you. (Yes, we could get into the discussion that SLAAC isn't technically an assignment in this context but stateful DHCPv6 is, but let's not go there). Basically, under the current policy, based on the English language, letting any 3rd party use your IPv6 PI address space is a violation of the policy.

I beg to differ, it's not about (interpretation of) English language. The policy defines, what »to assign« means in the context of the policy. Article 2.6. states: »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.«

(Which, btw, means there's no difference between PA and PI here. Thus, End Users must not use DHCPv6 nor WiFi, with NCC'scurrent interpretation. Eeks.)

The WiFi is part of my (internet-facing) infrastructure I operate. It needs address space to work as designed, so where do I take that from? My routers, switches and internal systems are numbered from my PI space; do I need non-PI space for my WiFi? (Another /48 for maybe 20 devices?)

Anyway, I don't intend to nit-pick here; I would like to understand why things are as they obviously are, although there already are definitions for the terms used. Then, I'd like to get things fixed in a way that looking at the »document [which] defines registry policies for the assignment and allocation of globally unique IPv6 addresses to Internet Service Providers (ISPs) and other organisations« (self-definition of ripe-655) it is clear what can be done with the address space requested and/or received and when the request can/will be denied. Currently, to me it's anything but clear from that document, as hidden rules exist that are neither documented nor mentioned.

> And 3rd party usage of IPv6 PI addresses is currently not allowed.

Well, if reading the policy that way, neither is it for non-PI space?

> What this policy tries to define is what sub-assignment, and define it as a /64 or more. So letting 3rd parties connect to your WiFi (which will assign them a couple of addresses) is fine, as is letting someone host a server on your network. But you're not allowed to give them their own /64 or more. If you do that then (under the proposed policy text) you are sub-assigning, which isn't allowed.

This is because »assignment« isn't used as defined by the policy, imho. If the proposed change solves the issue that fellow Freifunkas can not get IPv6 PI space, well, +1. But as WiFi is mentioned nowhere, this looks like wishful thinking to me.

Let's play it through: The policy change gets approved and implemented, and now a /64 of my IPv6 PI for my WiFi is ok. (And giving a /64 or less to my kids/neighbour/barber is as well?) But, I actually operate two WiFis, one for the general public and one for my family. Thus, I now use a /63 in total, but only a /64 each, for WiFi. Ok, not ok?Ok, as: »Within the context of these policies, a sub-assignment is an assignment of a length of /64 or shorter.«

(Actually, it would not be ok, as »/64 or shorter« still prohibts use of /64 for e. g. WiFi. The proposal therefore should read »/63 or shorter« or »shorter than /64«, I think, or SLAAC is not an option anymore.)

> Speaking as a chair: this issue has been around for a long time, and it keeps coming up. Without us (this WG) giving extra guidance to the RIPE NCC their interpretation of what we mean by "sub-assignment" can only be based on the English language, where assignment without any further qualification/quantification means *any* assignment, even if it's just a single address. So I would like to properly define in policy what we as a working group would like to happen.

That sums up pretty well my issues with the proposed change (while I still see a clear definition of »assignment« in the policy and wonder why only me understands it as that; is my understanding of the English really that flawed?).

Regards,
-kai


P.S. I don't aim for IPv6 PI for the WiFi part of our Freifunk setup; I'm just tired of renumbering 10+ systems and 20+ tunnels on every change of the upstream used, thus I looked into getting IPv6 PI, which led me here. Renumbering really sucks and I'm currently looking into NPTv6 as the ultimate solution to that; especially, as IPv6 PI obviously comes with too many hidden strings attached. And if it's in place at the egdeanyway, NPTv6 for the WiFi part comes for free. NATs are good, it seems.

-- 
Kai Siering                        Schalückstraße 107, 33332 Gütersloh
eMail: Kai.Siering at uu.org     ISN: 98735*1796 × Phone: +49 172 8635608
----------------------------------------------------------------------
"Getdate firmly  believes that years after 1999 do not exist;  getdate
 will have to be killed by the year 2000."
             -- From the "Bugs" section of cnews-020592/libc/getdate.3