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

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



On 1/21/08, Kevin Day <toasty@dragondata.com> wrote:
>
> 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


Does this not seem like an Operating System problem?  It seems to me
that ::ffff:0:0/96 should never really be seen on the wire.  Of course
the question of how this actually works is still very interesting.
One wonders what other 6to4 relays do with these packets.
Fascinating.