[db-wg] More specific INET6NUM for IPv6 PI

Hi Tobias,

I don't think that having more specific inet6num objects of PI
assignments would help *external parties* in any way with debugging.
Knowing a /56 belongs to Santa's Workshop WiFi or his router's
loopbacks does not help me at all if I can't reach the /48. For that,
using the contact details from the /48 should help fix the problem.
Also works for any problem with any /52, /64 or even up to /128 inside
that /48.

Having such specific objects in the db might help *external parties*
map Santa's internal addressing policies. If Santa wants that info to
be public he can publish it on a page referenced somewhere in remarks:
instead of creating smaller inet6num objects with the same contact
details as the /48 and only a different description. Or use PA space.

I think such information is probably a better fit inside some internal
IPAM of Santa's ORG so their internal teams can debug and fix issues
that might occur.

Best,

Radu

On Fri, Mar 31, 2023 at 1:42 AM Tobias Fiebig via db-wg <db-wg at ripe.net> wrote:
>
> 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
>
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/