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 <[email protected]> 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 ([email protected] 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 [email protected] > > > -- > > To unsubscribe from this mailing list, get a password reminder, or change > your subscription options, please visit: > https://lists.ripe.net/mailman/listinfo/db-wg >
-- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
