[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 Jan 27, 2008, at 12:54 PM, Rémi Després wrote:


1.
 I agree with Erik that this is an OS problem.
IMHO, he dual stack OS of the host, when it has to send a packet to a mapped address, should use its IPv4 stack (ref RFC 2553 - 3.7) If the application has selected this address as destination, it must be because no IPv6 address other than IPv4 mapped was available (no address with a longer source-destination match, in particular none with at least a 2000::/3 match).
 It is therefore guaranteed that the destination is IPv4-only.
 Using the IPv4 stack then works nicely.
 Would FreeBDSD have done it, there not have been any problem.



Just to clarify, since I think I might have not stated this part clearly...

FreeBSD was running on the 6to4 relay server, the clients in question(the systems actually initiating the traffic) appeared to all be Windows based.

FreeBSD doesn't seem to ever try to send ::ffff:0:0/96 over a 6to4 connection, which I believe is the correct thing to do. The original client shouldn't have used its v6 stack at all when accessing a v4 mapped address.

On FreeBSD:

freebsd# nslookup -querytype=AAAA mappedtest.your.org

Non-authoritative answer:
mappedtest.your.org	has AAAA address ::ffff:204.9.48.81

send some test traffic to it:

freebsd# telnet mappedtest.your.org 6789
Trying ::ffff:204.9.48.81...
telnet: connect to address ::ffff:204.9.48.81: Connection refused
telnet: Unable to connect to remote host

then watch on tcpdump:

19:38:55.191823 IP freebsdbox.63865 > 204.9.48.81.6789: S 811563213:811563213(0) win 65535 <mss 1460,nop,wscale 4,nop,nop,timestamp 3955202055 0,sackOK,eol> 19:38:55.192043 IP 204.9.48.81.6789 > freebsdbox.63865: R 0:0(0) ack 811563214 win 0

Nothing touched 6to4 there.


However, trying the same thing from an XP box using 6to4:

14:18:44.780353 IP 69.31.99.17 > 192.88.99.1: IP6 2002:451f:6311::451f: 6311.1026 > ::ffff:204.9.48.81.6789: S 2991418190:2991418190(0) win 16384 <mss[|tcp]>


So, I think it's XP not doing the right thing here... XP should be selecting its own v4 stack instead of trying to shove packets to ::ffff:0:0/96 down 6to4... correct?

I've got a contact in Microsoft that works with their v6 implementation that I'll get in touch with to see if I can figure out why Windows is doing this.

-- Kevin