[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 3:16 PM, Brian E Carpenter wrote:
On 2008-01-28 09:21, Kevin Day wrote:
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
That isn't necessarily so. If the client is attempting to reach
a SIIT translator, such as a NAT-PT, the mapped address should
be used, and should be routed to the translator. In that case,
there's no reason that the path to the translator shouldn't start
out as 6to4. IMHO this needs to be a configurable behaviour.
It's unfortunate, to say the least, that mapped addresses have
these two different uses.
While I understand translation is a slightly different case, as a 6to4
relay operator I'm still not sure what the relay is supposed to do
with a mapped destination address.
The only options I see are:
1) The relay converts it back to a v4 packet and sends it off using
the client's v4 address.
In my tcpdump example:
IP 18.104.22.168 > 22.214.171.124: IP6 2002:451f:6311::451f:6311.1026
> ::ffff:126.96.36.199.6789: S 2991418190:2991418190(0) win 16384 <mss[|
would convert 2002:451f:6311::451f:6311 back to 188.8.131.52, and send
that to 184.108.40.206.
This is going to fail because of RPF or other anti-spoofing methods.
This also doesn't work because the client is considering this a v6
connection, and is expecting replies back to 2002:451f:6311::451f:6311.
2) The relay passes the packet through to the gateway as though it
were any other v6 packet.
draft-itojun-v6ops-v4mapped-harmful-00.txt seems to say that this is a
bad idea. I realize it's was only a draft, but the BSD's were
convinced by its arguments, won't accept or transmit v4 mapped
addresses on the wire.
Just to confirm I'm not crazy, I forced some onto the wire and our
Juniper routers just dropped them as well.
FreeBSD right now has the following code/comment in it that refuses
any v4 mapped addresses coming into it from the outside at all:
* The following check is not documented in specs. A malicious
* party may be able to use IPv4 mapped addr to confuse tcp/
* and bypass security checks (act as if it was from
127.0.0.1 by using
* IPv6 src ::ffff:127.0.0.1). Be cautious.
* This check chokes if we are in an SIIT cloud. As none of
* support IPv4-less kernel compilation, we cannot support SIIT
* environment at all. So, it makes more sense for us to
* malicious packets for non-SIIT environment, than try to do a
* partial support for SIIT environment.
if (IN6_IS_ADDR_V4MAPPED(&ip6->ip6_src) ||
The 6to4 relay code goes one step further and blocks both mapped AND
if (IN6_IS_ADDR_V4COMPAT(in6) || IN6_IS_ADDR_V4MAPPED(in6))
So, to sum up:
A 6to4 relay can't convert the packet back to a v4 packet. The client
is expecting a reply to come back to it on its v6 stack, and you'd be
dictating that public 6to4 relays would have to be able to spoof
traffic from the world.
A 6to4 relay can't just treat it like a normal v6 address, because
relays (mine anyway) won't forward packets that are to v4 mapped
addresses. Additionally, our router won't do anything with them either.
I understand SIIT and NAT-PT use them locally, but... I can't imagine
a scenario where a SIIT box is going to be sending 6to4 encapsulated
traffic to a 6to4 relay?
When you say "there's no reason that the path to the translator
shouldn't start out as 6to4", do you mean v6 only boxes behind the
translator? If so, they've got no reason to talk to a 6to4 relay at all.
I guess what I'm asking is, if you're saying that this really is
desirable to do, what do you want a 6to4 relay to do with these packets?