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

[Alain Durand <alain_durand@cable.comcast.com>]

The AAAA records:
mail.comcast.net        canonical name = mail.g.comcast.net.
mail.g.comcast.net      has AAAA address ::ffff:63.240.76.10

were not something we configured but were dynamically generated as a side
effect of a bug introduced by a certain piece of hardware in our network. A
temporary work around has been put in place until the bug is fixed. This is
just yet another confirmation that there should be no AAAA published (either
by configuration or dynamically generated) until all the pieces are in
place.

AAAA records containing IPv4 mapped addresses do not seem to be a good idea
anyway, it might be worth an addendum to RFC4472.

Thank you to those who pointed out this problem.

  - Alain.


On 1/23/08 1:03 PM, "Erik Kline" <ekline@ekline.com> wrote:

> 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.
>