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

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

I think there are two other options for the relay.

3) Forward the packet to your local friendly NAT-PT box.
This is really a version of #2 - in fact it's the only
case I can think of where #2 would be useful. Of course,
most people don't have a local friendly NAT-PT.

4) Drop it. That would be my preference as a default.

    Brian

On 2008-01-28 11:10, Kevin Day wrote:
> 
> 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
> 
>