[address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)

On 08.11.2017 11:20, JORDI PALET MARTINEZ wrote:
> Ok, here is it then. Hopefully we have a lot of fun and good noise ;-) (that's music?)
>
> The main idea is to allow what Max (and many other people) needs in PI, but not having restrictions.
>
> For that, what I’m proposing is:
>
> 1) Change the actual definition of Assign in 2.6, to:
> 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, with the exception of Provider Independent (PI).

To me, this wording makes things even worse. This makes PIv6 more adorable (less restricted) and will lead to more confusion instead of less.

> 2) Remove last paragraph in 7. IPv6 Provider Independent (PI) Assignments
> So, REMOVE: The PI assignment cannot be further assigned to other organisations.

I'm happy with the "no subassignent" restriction (as in: you cannot enter a bigger prefix in the RIPE DB, even as an LIR), I challenge NCC's interpretation of allowing third party users use my PI space temporary being a sub-assignment (guest WiFi/Freifunk case).

> Rationale:
>
> a. Arguments Supporting the Proposal
> This proposal will avoid the situations of breaking existing policy when a network using PI is using the addressing space for point-to-point links or in cases such as providing connectivity to employee or visitor devices (BYOD), hot-spots, and similar situations.
> At this way, regardless of if a single /128 or /64 is sub-assigned, and independently of what technology is used for that (SLAAC, DHCPv6, DHCPv6-PD), the restriction is no longer an issue.

My employees are part of my organisation, no issue there.

Visitors are what is objected by the NCC, as they are not part of the organisation that holds the PI assignment. But then the RIPE NCC is in breach with it's own interpretation when using their PI space on a RIPE Meeting's public network (wired & wireless): not every WiFi user at a RIPE Meeting is an employee of the RIPE NCC. So, next time we'll see the RIPE NCC requesting a temporary PA (v4 and v6) from the providing ISP for the Meeting's network? Similarily, as my family isn't me, I may not allow them to use PI space assigned to me? But then, what's PI good for anyway?

Any service that's setup/operated/funded by the assignee (the holder of (PI) space) should be considered proper use of these Internet resources, as far as the IR is concerned.

> b. Arguments Opposing the Proposal
> It can be argued that this proposal could increase the number of PI request to RIPE NCC.
>
> Mitigation/counter-argument: This is not an issue and should not be considered as a “bad-effect”.
>
> The resulting policy could be used to circumvent the allocation policy, avoiding creating a LIR.
>
> Mitigation/counter-argument: This seems not to have sense as there must be a justification process anyway, and because the starting point is /48, an ISP willing to connect customers, will really want to be an LIR. Furthermore, if we want to be restrictive on this, we could add a limitation that the maximum sub-assignment can be /64.

So I need a /48 per WiFi I use (as each requires an /64 and two "sub-assignments" therefore would exceed the limit)? Does not look like it solves any issue ;)



Still: I don't think ripe-684 needs an update. At fault is the RIPE NCC's, highly inconsistent, interpretation of the term "sub-assignment". ripe-684's definition of "assign" states (in 2.6): "Assignments must only be made for specific purposes documented by specific organisations and are not to be sub-assigned to other parties".

If a /128 for a device that doesn't belong to the organisation holding a IPv6 assigment is a "sub-assignment", there is *no* way for *any* organisation to (in accordance of RIPE NCC's interpretation) provide externals with public IPv6 addresses. By any means. Regardless if the organisation is an IR or not. (Well, an IR could formally "assign" address space from their allocated, unassigned pool, if the End User comes with "Internet infrastructure they operate"; different story.)

I somewhat doubt that RIPE NCC teaches this interpretation to (old and) new LIRs for evaluating PA requests. But then there is no justification to interpret the definition of "assign" in 2.6 differently for PI.

As I don't think the intent of ripe-684 was to prevent the use of IPv6 on guest or even public WiFi, in coworking spaces, hotels or at meetings, the sane thing to do is to abolish this interpretation of an /128 being a "sub-assignment" within the RIPE NCC. It's nowhere in the policy text; on the contrary: This "/128 is a sub-assignment" interpretation even contradicts ripe-684. Quoting 5.4.1. ("Assignment address space size"): "End Users are assigned an End Site assignment from their LIR or ISP. The size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (only one subnet is anticipated for the End Site)." If the policy document(!) itself considers a /64 as the minimal size of an assignment to End Users, there is no ground for interpreting a /128 as one, sub or otherwise.

On the principle of don't fix it if it ain't broken, I'm therefore still againt this proposal. Let's fix the real issue, not complicate a proper policy text.

> Thoughts?

Yepp, voiced ;)

Regards,
-kai