Thus spake Delong.com (owen@delong.com) on Wed, Oct 11, 2023 at 12:44:35PM -0700:
On Oct 11, 2023, at 11:50, Dale W. Carder <dwcarder@es.net> wrote:
Thus spake Delong.com via NANOG (nanog@nanog.org) on Tue, Oct 10, 2023 at 04:52:07PM -0700:
However, IF YY is paying attention, and YY wants to advertise 2001:db8::/32 as well as allow 2001:db8:8000::/36 and 2001:db8:f000::/36, I would expect AS YY would generate ROAs for 2001:db8::/32 with ORIGIN-AS=YY MAXPREFIXLEN=36 2001:db8:0::/33 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:8000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36 2001:db8:9000::/35 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:a000::/34 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:c000::/34 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:e000::/36 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:f000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36
Double check, but offhand I believe in this case you do not need all these AS0 ROA's. Any validated ROA payload fully matching should be all you need for it to be valid, and anything that is covered by a vrp but not matching is invalid.
So, I think you can do 2001:db8::/32 with ORIGIN-AS=YY MAXPREFIXLEN=32 2001:db8:8000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36 2001:db8:f000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36
Dale
My understanding is that the 2001:db8::/32 max=32 would block the /36s from being considered valid (in order to prevent someone with trust anchor B overriding the policy of someone with trust anchor A).
Since all the trust anchors are ::/0, I think that was deemed important.
I could be wrong, like you, I would need to double check the details.
I found a working example from within our customer cone: https://rpki-validator.ripe.net/ui/2620%3A6a%3A%3A%2F48/3152 Dale