Subject: 32.1.0.0/16 and v6 collateral damage

From: Kevin Day <[email-masked]>
Date: Tue, 4 Dec 2007 21:04:01 -0600

(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

---

From: Gert Doering <[email-masked]>
Date: Wed, 5 Dec 2007 09:00:12 +0100

Hi,

> please ignore any duplicates)

I see it for the first time, so the first time definitely didn't make
it here.

> [ .. ]

Ugh.

Have you been able to pinpoint the specific device in the path where the 
breakage occured?  If yes, do you know the model and software version number?

[..]
> 32.2.0.0/16 (2002::)? 

I haven't.  (Well, IPv6 peers show up in the BGP mib with 32.1.0.0 
addresses, but that's a completely unrelated phenomenom).

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  110584

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 5 Dec 2007 06:35:26 -0800

On 4 dec 2007, at 19:04, Kevin Day wrote:

> 32.2.0.0/16 (2002::)? Does anyone know if McLeod suffered any  
> problems from 3ffe:: breaking 63.254.0.0/16 ?

I saw something a bit like this once. The prefixes were the normal  
IPv4 table, but the next hop addresses were something like 32.x.x.x or  
35.x.x.x IIRC. Turned out that on an IPv6 BGP peering session, both  
ends forgot to specifically disable the IPv4 address family, so IPv4  
routes were exchanged but BGP was unable to resolve an IPv4 next hop  
address because this happened over IPv6, hence the strange next hop  
addresses.