AS3356 has been announcing 2000::/12 for about 3 hours now, an aggregate covering over 23K prefixes (just over 25%) of the IPv6 DFZ.
Prayers for anyone impacted, the team announcing it, and the team resolving the issue.
Ryan Hamel
AS3356 has been announcing 2000::/12 for about 3 hours now, an aggregate covering over 23K prefixes (just over 25%) of the IPv6 DFZ.
Prayers for anyone impacted, the team announcing it, and the team resolving the issue.
Ryan Hamel
interesting that this is leaking outside supposed RPKI OV boundaries as well.
For example:
6762 3356
2914 3356
174 3356 (apologies to 174, I forget if they signed up to the 'doin
ov now' plan)
These as well:
3257 3356
3491 3356
They probably leaked a hold down route.
Ryan Hamel
How can RPKI / OV prevent such a leak when there is no ROA for 2000::/12, what would 6762|2914|174|* invalidate against? Until a future where everything is ‘valid’, RPKI is unable to pare out less-specific conflicts.
It does look like 3356 pulled the announcement, which is good.
How can RPKI / OV prevent such a leak when there is no ROA for 2000::/12,
If all ASes participated, no „unknowns“, unknowns could be dropped, ….
How can RPKI / OV prevent such a leak when there is no ROA for 2000::/12,
If all ASes participated, no „unknowns“, unknowns could be dropped, ….
yea that might be a tad dangerous today
and don's right unknown is hard today
(darn you don for being
practical! )
crud.. but iRR filters!
That would be a nice start
while i think the announcement is, shall we say, embarrassing, i do not
see how it would be damaging. real/correct announcements would be for
longer prefixes, yes?
randy
Hi all,
Oh, that’s a nice write-up. I must admit that it didn’t occur to me that e.g 2000::/12 was likely something much more specific, but that someone missed the (probably) 6, 7, or 8 at the end, even though I’ve done this a few times myself…
W
I know of a few people in a Discord that filter out anything bigger than /16 routes, would this be wise to implement as a best practice?
I know of a few people in a Discord that filter out anything bigger
than /16 routes, would this be wise to implement as a best practice?
once upon a time, a very large provider took two /8s and announced as a
/7. a vendor who thought a /8 was as short as they would ever see had
routers fall over in a receiving large provider.
do not hard code social theories. remember 640k.
randy
Putting on a probably-overly-paranoid hat for a moment…
If I announce 2000::/12, seemingly as an innocent error,
it won’t break most people’s routing, and is likely to be simply
chalked up as a copy-paste error, or other human “oops”.
But if I happen to be running a promiscuous packet capture
on a box that the “erroneous” routing table entry ultimately
resolves to, I warrant there’s a certain amount of legitimate
packet streams I could collect here and there, any time a
router processes a WITHDRAW update message for a more
specific prefix within the range, before a new ANNOUNCE
update message is processed.
I’m not going to get a great deal of information, as most
simple prefix updates happen within the same update
message; but during periods of higher internal churn in a
network, you may have brief periods during which the more
specific route is withdrawn before being re-announced, during
which I’d be able to harvest packets destined for other networks.
As I said–I’m probably being overly paranoid, but I can’t help but
wonder what packets such a collector might see, if left to run for a
week or two… ^_^;
Thanks!
Matt
A decade ago it looked like this…
Geoff
The Internet delivers when we need it the most!
https://is2000slash12announcedagain.com/
Props to Ben Cartwright-Cox