32.1.0.0/16 and v6 collateral damage

[Kevin Day <toasty@dragondata.com>]

(resending because I don't think this made it through last time,  
please ignore any duplicates)


While hopefully this was an isolated incident, I thought I'd share a  
really strange problem that came up this week.

We had an ISP contact us saying we were announcing 32.1.73.0/24 (part  
of AT&T's space) which was breaking something for them. In fact,  
random subnets in 32.1.0.0/16 were showing up in their routing table  
going to all sorts of ASNs, which was confusing to them.

I checked our config, and could find no reason we would be announcing  
that /24 anywhere. It wasn't in our table, our prefix filters wouldn't  
have allowed it anyway, nor would our upstreams' filters. They flapped  
their BGP sessions, reloaded their router, and kept seeing it come  
back. Finally I did a little mental math on that address. Our v6 /32  
is 2001:4978::. 0x20 = 32. 0x01 = 1. 0x49 = 73. Somehow, a router  
translated our v6 address into a v4 address, and passed it through.  
After a lot of head scratching at various NOCs, we identified a router  
between the ISP that contacted us and our network that had converted  
v6 addresses in its table into v4 addresses, preserved their AS path  
and other attributes, then readvertised them to customers.

The breakage was pretty limited, and went away after a reload. But, it  
makes me a bit curious as to how often things like this will reoccur  
when routers/hosts/software that have had zero v6 testing start  
getting exposed to v6 addresses. I'm sure it's unlikely that most  
brokenness will result in an application still working, yet converting  
a v6 address into some kind of v4 address.

Has anyone else seen any breakage involving 32.1.0.0/16 (2001::) or  
32.2.0.0/16 (2002::)? Does anyone know if McLeod suffered any problems  
from 3ffe:: breaking 63.254.0.0/16 ?

-- Kevin