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
