[rpd] policy proposal - Clarification on IPv6 Sub-Assignments

[Sander Steffann]

Hi,

> I see two choices:
> 
> Option 1)
> 
> The fact that is non-permanently provided to third parties shall not be considered a sub-assignment. The provision of addressing for permanent connectivity or broadband services is still considered a sub-assignment, with the exception of point-to-point links.
> 
> Option 2)
> 
> The fact that a unique address or even a unique /64 prefix is non-permanently provided to third parties, shall not be considered a sub-assignment. The provision of addressing for permanent connectivity or broadband services is still considered a sub-assignment, with the exception of point-to-point links.
> 
> Option 1 will allow any number of address, option 2 will allow only up to /64. In both cases only for temporary usage.
> 
> What are your opinions?

Both have a major shortcoming: Organisations that use IPv6 PI space on their network can have 3rd-party equipment connected to it:
- Hosting a server for a friend
- 3rd party appliances
- Security devices (camera's etc) that are managed by an external security company
- Same for building management systems
- etc

Of course I could consider each connection a point-to-point link and circumvent the policy that way... But this feels like we're using the wrong approach to improve this policy here. I would like a policy that aligns the policy text with the actual operation of networks:
- If an LIR gives address space to a 3rd party so they can configure and manage their own network with it, then it is a sub-assignment
- If an LIR gives address space to a 3rd party but the LIR is the one configuring and managing the network then it is not a sub-assignment

In short: sub-assigning == delegating management and responsibility

If I manage a network and connect 3rd-party devices to it, it is still my network with "my" address space. Only when I delegate address space so the 3rd party can manage it themselves should it be considered a sub-assignment.

I realise that "management" and "responsibility" are not strictly defined terms (and on a different layer in the network stack), but such is reality. I'd like a policy that matches operational practice and reality, not arbitrary technical barriers.

Cheers,
Sander