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

Anno domini 2017 JORDI PALET MARTINEZ scripsit:

Hi,

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

> Thoughts?

I like the idee, but I'm totally with Nick on this one: It's a much
larger change - which I support - but don't think, that we can get
this implemented into policy in the near future. So I propose to *now*
implement my proposal with the smaller change and then get the bold
move of lifting more restrictions or even lifting the distinction
between PI/PA going.

I think it's safe to predict that if we shift to your approach right
now, we will still be discussing this on the next RIPE meeting, or
even the one after that as the area of things touched by this change
is considerably larger, as pointed out by others already. That way we
solve the real time problem - which we all agree on, right? - right
now and make PI great again, and then have time to make the world and
even better place afterwards. :-)

Best
Max