<div dir="ltr">Hi Tobias,<div><br></div><div>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.</div><div>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.</div><div><br></div><div>I am not strictly opposed to allowing sub-assignments within the same org.</div><div>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.<br></div><div>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.</div><div></div><div><br></div><div>-Cynthia</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 31, 2023 at 1:42 AM Tobias Fiebig via db-wg <<a href="mailto:db-wg@ripe.net">db-wg@ripe.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Heho,<br> <br> for some unrelated reasons I have been thinking about more specific<br> INET6NUM objects for IPv6 PI assignments that still list the same<br> organization but detail a specific purpose of the more specific to aid,<br> e.g., debugging and information sharing.<br> <br> As this is a relatively quick thought that crept up to my brain (I<br> don't want to request or suggest anything; More interested in<br> understanding the current situation), i'd really appreciate some input,<br> mainly to understand where i might have missed some context.<br> <br> With best regards,<br> Tobias<br> <br> # Description<br> <br> The following might, for example, be the use of a /48 PI assignment:<br> <br> 2001:db8:1234::/48<br> <br> 2001:db8:1234::/52 - Public Internet Infrastructure<br> 2001:db8:1234::/56 - Network; Loopbacks, transfer etc.<br> 2001:db8:1234:100::/56 - Infrastructure PoP1 (mail, web, DNS)<br> 2001:db8:1234:200::/56 - Infrastructure PoP2 (backup, DNS)<br> <br> 2001:db8:1234:f000::/52 - Office France<br> 2001:db8:1234:f000::/56 - Office (infra) France<br> 2001:db8:1234:f100::/56 - Office (wired) France<br> 2001:db8:1234:f200::/56 - Office (wifi) France<br> 2001:db8:1234:f300::/56 - Office (guest wifi) France<br> <br> 2001:db8:1234:d000::/52 - Office Germany<br> 2001:db8:1234:d000::/56 - Office (infra) Germany<br> 2001:db8:1234:d100::/56 - Office (wired) Germany<br> 2001:db8:1234:d200::/56 - Office (wifi) Germany<br> 2001:db8:1234:d300::/56 - Office (guest wifi) Germany<br> <br> Dedicated INET6NUM objects could be useful for:<br> - The per-office-country /52 to properly attribute geoloc and direct to<br> the right (local) role contacts (<a href="mailto:noc.fr@example.com" target="_blank">noc.fr@example.com</a> vs. noc.de@)<br> - Indicate that the internal office wifis have a /64 on each client<br> - Indicating the status of the guest wifis and a different abuse<br> department, as they--containing externals--might have to be handled<br> differently, and there is no prefix delegation (PI requirements)<br> - Creating objects for pop1/pop2 infra networks (noc.infra@, detailing<br> use for public-facing/DMZish systems)<br> - Creating objects providing additional information on more specifics<br> that may show up in traceroutes<br> - ...<br> <br> In all cases, the ORG of the objects would remain the same as that of<br> the assigned /48.<br> <br> This is currently not possible in the DB as:<br> - There is no fitting status:, and ASSIGNED PI can not use by LIR/end-<br> user MNTs<br> - The creation of more specific INET6NUM objects is not allowed in<br> general<br> <br> Arguments against allowing more specifics below PI are:<br> <br> # The org should just request one PI per pop/use (infra/de/fr)<br> <br> Here, I would argue, that this does not necessarily conform to address<br> space conversation; Technically, the /48 is enough for this specific<br> org.<br> <br> Also, while RIPE 738 2.6 notes that assignments should only be made for<br> _specific_ purposes, it explicitly lists some of the use-cases and<br> splits described above. Furthermore, when requesting PI, the ability to<br> use more specifics from a /48 is a common argument why only a /48 can<br> be provided to one end-user with multiple pops.<br> <br> Similarly, requesting multiple /48s increases the numbering overhead<br> for the end-user, and even if one larger-than /48 assignment was made<br> (which is a discussion out-of-scope and for another wg here), the issue<br> of creating more specifics for the /48s would remain the same.<br> <br> # Policy forbids it<br> <br> I am actually not sure whether ripe-738 actually forbids this. Reading<br> Sec. 2.6, I only see a restriction to specific purposes (see above) and<br> a restriction of more specifics being 'sub-assigned to other parties',<br> which is reiterated in the preamble of Sec. 7.<br> <br> In my reading, though, that does not mean that an assignee could not<br> create more specific INET6NUM to more accurately document the extend of<br> the specific use of the assignment, as long as the ORG remains the<br> same.<br> <br> -- <br> Tobias Fiebig<br> M <a href="mailto:tobias@fiebig.nl" target="_blank">tobias@fiebig.nl</a><br> <br> <br> -- <br> <br> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: <a href="https://mailman.ripe.net/" rel="noreferrer" target="_blank">https://mailman.ripe.net/</a><br> </blockquote></div>