[db-wg] More specific INET6NUM for IPv6 PI

Heho,

for some unrelated reasons I have been thinking about more specific
INET6NUM objects for IPv6 PI assignments that still list the same
organization but detail a specific purpose of the more specific to aid,
e.g., debugging and information sharing.

As this is a relatively quick thought that crept up to my brain (I
don't want to request or suggest anything; More interested in
understanding the current situation), i'd really appreciate some input,
mainly to understand where i might have missed some context.

With best regards,
Tobias

# Description

The following might, for example, be the use of a /48 PI assignment:

2001:db8:1234::/48

2001:db8:1234::/52      - Public Internet Infrastructure
2001:db8:1234::/56      - Network; Loopbacks, transfer etc.
2001:db8:1234:100::/56  - Infrastructure PoP1 (mail, web, DNS)
2001:db8:1234:200::/56  - Infrastructure PoP2 (backup, DNS)

2001:db8:1234:f000::/52 - Office France
2001:db8:1234:f000::/56 - Office (infra) France
2001:db8:1234:f100::/56 - Office (wired) France
2001:db8:1234:f200::/56 - Office (wifi) France
2001:db8:1234:f300::/56 - Office (guest wifi) France

2001:db8:1234:d000::/52 - Office Germany
2001:db8:1234:d000::/56 - Office (infra) Germany
2001:db8:1234:d100::/56 - Office (wired) Germany
2001:db8:1234:d200::/56 - Office (wifi) Germany
2001:db8:1234:d300::/56 - Office (guest wifi) Germany

Dedicated INET6NUM objects could be useful for:
- The per-office-country /52 to properly attribute geoloc and direct to
  the right (local) role contacts (noc.fr at example.com vs. noc.de@)
- Indicate that the internal office wifis have a /64 on each client
- Indicating the status of the guest wifis and a different abuse
  department, as they--containing externals--might have to be handled
  differently, and there is no prefix delegation (PI requirements)
- Creating objects for pop1/pop2 infra networks (noc.infra@, detailing
  use for public-facing/DMZish systems)
- Creating objects providing additional information on more specifics
  that may show up in traceroutes
- ...

In all cases, the ORG of the objects would remain the same as that of
the assigned /48.

This is currently not possible in the DB as:
- There is no fitting status:, and ASSIGNED PI can not use by LIR/end-
  user MNTs
- The creation of more specific INET6NUM objects is not allowed in
  general

Arguments against allowing more specifics below PI are:

# The org should just request one PI per pop/use (infra/de/fr)

Here, I would argue, that this does not necessarily conform to address
space conversation; Technically, the /48 is enough for this specific
org.

Also, while RIPE 738 2.6 notes that assignments should only be made for
_specific_ purposes, it explicitly lists some of the use-cases and
splits described above. Furthermore, when requesting PI, the ability to
use more specifics from a /48 is a common argument why only a /48 can
be provided to one end-user with multiple pops.

Similarly, requesting multiple /48s increases the numbering overhead
for the end-user, and even if one larger-than /48 assignment was made
(which is a discussion out-of-scope and for another wg here), the issue
of creating more specifics for the /48s would remain the same.

# Policy forbids it

I am actually not sure whether ripe-738 actually forbids this. Reading
Sec. 2.6, I only see a restriction to specific purposes (see above) and
a restriction of more specifics being 'sub-assigned to other parties',
which is reiterated in the preamble of Sec. 7.

In my reading, though, that does not mean that an assignee could not
create more specific INET6NUM to more accurately document the extend of
the specific use of the assignment, as long as the ORG remains the
same.

-- 
Tobias Fiebig
M tobias at fiebig.nl