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@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@fiebig.nl
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@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@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@fiebig.nl
--
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
Hello, I've wished for this feature for ages as well, because TREX hosts things like a public NAT64/DNS64 testbed, mail servers for a Finnish non-profit mail forwarder service and a 9.9.9.9 node. Among other things. All of these have separate admin groups, and I'd love to be able to document the address blocks and point the abuse contacts directly to the right place for speed and efficiency. I'd like to be able to do the same with IPv4 PI as well. Best Regards, On 3/31/23 04:42, Cynthia Revström via db-wg wrote:
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@ripe.net <mailto:db-wg@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@example.com <mailto:noc.fr@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@fiebig.nl <mailto:tobias@fiebig.nl>
--
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 <https://lists.ripe.net/mailman/listinfo/db-wg>
-- +358 4567 02048 / http://www.trex.fi/ Aleksi Suhonen / TREX Regional Exchanges Oy `What I need,' shouted Ford, by way of clarifying his previous remarks, `is a strong drink and a peer-group.' -- Douglas Adams, Life the Universe and Everything
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@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@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@fiebig.nl
--
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
participants (4)
-
Aleksi Suhonen -
Cynthia Revström -
Radu Anghel -
Tobias Fiebig