[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