maximum ipv4 bgp prefix length of /24 ?

Thu Oct 12 08:42:07 UTC 2023

.

On 12/10/2023 10:00, Owen DeLong wrote:
>[...]
>>> 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
>>
>> As Dale suggested in another email[1], it's better to just cover ROAs for what you are advertising. Why?
> 
> If that works, perhaps… OTOH, I’m not sure it does. I’m not sure the /32 MAXLEN 32 wouldn’t prevent effectiveness of the /36 ROAs.
>>
>> 1. I can't confirm at this stage that all the implementation allows you to leave the maxLength field empty.
> 
> I can… It’s an Optional Field in the specification.

For the _specification_ yes. But by "Implementation" I'm referring to 
whatever either the RIR (those using hosted mode) or your own RPKI 
Certificate Authority (those using the delegated mode) will allow.

>> 2. If you want to follow that logic, what you are trying to accomplish with AS0 is basically the *complement* of what you are not advertising. I believe that will be much more work and you might miss a lot of specifics. e.g : under your 2001:db8::/32 , do not forget you have 16x/36, 2x/33,4x/34,... You will have to insert statement for every single of them.
> 
> Yes, but if I issue a /34 AS0 with no MAXLEN, that _SHOULD_ mark ALL more specifics as invalid.
> 
> If that doesn’t work, then you’re right, the AS0 ROAs are essentially useless, but then one has to wonder what value any RIR issued AS0 ROAs would have as well, since they would obviously be less specific.

I will let those with more experience than me provide clarifications here.

-- 
Willy Manga
@ongolaboy
https://ongola.blogspot.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20231012/5040c071/attachment.sig>