[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
mapped address.


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 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]>
would convert 2002:451f:6311::451f:6311 back to 69.31.99.17, and send that to 204.9.48.81.
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/ udp stack * 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 BSDs 
         * support IPv4-less kernel compilation, we cannot support SIIT
* environment at all. So, it makes more sense for us to reject any 
         * malicious packets for non-SIIT environment, than try to do a
         * partial support for SIIT environment.
         */
        if (IN6_IS_ADDR_V4MAPPED(&ip6->ip6_src) ||
            IN6_IS_ADDR_V4MAPPED(&ip6->ip6_dst)) {
                ip6stat.ip6s_badscope++;
                in6_ifstat_inc(m->m_pkthdr.rcvif, ifs6_in_addrerr);
                goto bad;
        }
The 6to4 relay code goes one step further and blocks both mapped AND compatible addresses: 

        if (IN6_IS_ADDR_V4COMPAT(in6) || IN6_IS_ADDR_V4MAPPED(in6))
                return -1;


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? 


-- Kevin