[db-wg] More specific INET6NUM for IPv6 PI

Hi Tobias,

There is a very good reason for why you probably don't want to use a /48
for more than one site and that is routing.
You pretty much can't get anything more specific than a /48 into the DFZ
and as most orgs using PI space probably don't have their own backbone
networks it wouldn't really work that well if you shared a /48 between
sites.

I am not strictly opposed to allowing sub-assignments within the same org.
However I kinda question if anyone actually wants this feature given how
you are likely not going to be using the same /48 in multiple sites unless
you are doing anycast.
Seems a bit like we would just be wasting the DB team's time with this
unless there is someone who actually wants/needs this.

-Cynthia

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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/db-wg/attachments/20230331/0cc6d1a5/attachment.html>