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

[Kevin Day <toasty@dragondata.com>]

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