Re: One socket per AF (Was: 6to4 using ::FFFF:0000:0000/96...)

[Kevin Day <toasty@dragondata.com>]

On Jan 28, 2008, at 9:44 AM, Rémi Després wrote:

> Jeroen Massar wrote :
> > But using it on the wire or when presenting it to users is  
> > definitely not.
> Why ???

The problem with presenting v4 mapped/compatibility addresses on the  
wire is that the behavior of such packets has been left undefined so  
far.

* How these packets should be routed is completely undefined. Should  
routers handle them as though they were normal v6 unicast addresses?  
Or should they look at the v4 address and route them the same way as  
though it were v4? What about "special" v4 addresses (127.0.0.1,  
multicast, etc)? From my very limited testing, it looks like Juniper  
routers drop them, even if you add specific routes within the /96s for  
them. Our very old Cisco sends back an ICMP unreachable,

* There seems to be no behavior for 6to4, Teredo or tunnel brokers to  
do that results in anything working when receiving packets destined to/ 
sourced from these addresses.

* There are profound security implications of allowing v4 mapped/ 
compatibility addresses into your network. I'm not aware of any  
firewall or security device that will handle v4 mapped/compatibility  
addressed v6 packets, while still handling any of the behaviors  
considered for v4. One example brought up on one of the FreeBSD  
mailing lists long ago, before "net.inet6.ip6.v6only" got defaulted to  
"1" (essentially turning off v4 compatibility address use) was  
something like:

# Add a firewall rule keeping everyone out of my telnet server. All  
packets from anywhere to 1.2.3.4 to port 23 are dropped.
ipfw add drop tcp from any to 1.2.3.4 23

Now, even if this host has no v6 configured beyond an auto-configured  
link-local address, it was possible to "telnet ::FFFF:0102:0304" from  
somewhere else on the LAN and bypass the firewall. Since then changes  
were made to prevent this sort of thing in the simplest of cases (v4  
compatibility addresses off by default, not accepting them over the  
wire at any time, etc).

While that's a really simplistic example, it shows that allowing these  
packets on the wire adds an attack vector that wouldn't be considered  
by most. Its giving attackers three different ways of expressing the  
same address(v4 native, mapped, and compatibility) which doesn't take  
much imagination to see being exploited.

* There's no standard for how clients/servers should respond to these,  
leading to breakage already. If you send a Linux server a packet  
to ::FFFF:0102:0304 it responds back using its v4 stack with 1.2.3.4.  
Windows uses its v6 stack, even when it probably doesn't make sense to  
(through 6to4/Teredo tunnels). Mac OS X and the BSDs drop all packets  
in ::FFFF:0:0/96 and ::/96 going in/out.


The only time I could ever see them being acceptable is on a link- 
local scope, and only to/from your gateway for NAT-PT, and only in the  
case where you've got a v6-ONLY box that must talk to a v4 device.  
Even then though, it feels wrong. :)