[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

6to4 using ::FFFF:0000:0000/96 (mail.comcast.net AAAA record weirdness)




We run a public 6to4 anycast relay. Today I received a complaint from a user that when he had his laptop connected to one ISP (that selected our anycast relay), he couldn't check his email. When he connected to a different ISP that used someone else's 6to4 relay, his email worked fine. I went around in circles with him for a while, because I couldn't understand how 6to4 was entering the equation when all his email access was going over v4. Sure enough, his v4 IP was talking to our 6to4 relay, and our relay was dropping the packets he was sending us.

After some digging, I added some debugging code to FreeBSD's 6to4 relay module to display why certain packets were being dropped. In about 10 minutes I found that there were 53 unique v4 IPs using our 6to4 relay that were attempting to send packets to ::ffff:3ff0:4c0a through the relay.

::ffff:3ff0:4c0a = 63.240.76.10 = mail.comcast.net

There were no other attempted accesses to anything using ::ffff:xxxx:xxxx, and FreeBSD's 6to4 code drops traffic to anything in that range. Doing a bit more digging, I discovered:

# nslookup -querytype=AAAA mail.comcast.net

Non-authoritative answer:
mail.comcast.net        canonical name = mail.g.comcast.net.
mail.g.comcast.net      has AAAA address ::ffff:63.240.76.10


This brings up a whole lot of questions....

1) What's Comcast trying to do with that AAAA record?

2) What 6to4 client implementation will try sending traffic to a v4 address like that over v6?

3) How is this even possibly working when this user is going through someone else's relay? 6to4 can't NAT. :)


I'm also seeing some 6to4 clients trying to send packets to :: 7f00:0001 that I haven't even begun trying to figure out the source of.

-- Kevin