[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 6to4 using ::FFFF:0000:0000/96


On Jan 27, 2008, at 9:54 PM, Brian E Carpenter wrote:


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.
That might be a little tough for those of us running public anycast relays to pull off, but perhaps locally sure. :)
I will say that this seems to be impossible for someone running a relay on any of the BSDs(Free/Net/Open/Dragonfly), or OS X. They will not accept or route any mapped(::FFFF:0:0/96) addresses at any time, so it's not possible without removing some code from in_input.c to even forward packets to a NAT-PT box.
However, I think this is a bit dangerous to allow by default for forwarding. It's not too hard to imagine cases where networks are using tunnels to gain v6 connectivity, and don't have their firewalls or other security set up to handle v4 packets being injected into their network from their tunnel box.
All this said, I'm seeing even more "unusual" traffic on our 6to4 relay that's outside mapped addresses showing up... In the past few days of watching, I've seen 6to4 clients try sending to the 6to4 relay packets with destination addresses in: 

Unicast:

Link Local (FE80::)
Site Local (FEC0::)
v4 compatibility (::/96)
v4 mapped (::FFFF:0:0/96)
All zeros (::)
Loopback (::1)
Obviously invalid addresses (BBBB:BBBB:BBBB:BBBB:BBBB:BBBB:BBBB:BBBB, etc) 

Multicast:

Unknown multicast (FF00::)
Node Local (FF01::)
Link Local (FF02::)
Site Local (FF05::)
I've been trying to trace the source of as many of these as is possible, but with the pretty anonymous nature of 6to4 it's a little difficult. Before I expend too much energy on this: 

1) Has anyone already done this digging before?

2) Is it of interest to anyone other than myself? :)
For right now, the default action of our relay is to drop all of these, but I'm mostly interested in what the clients are trying to accomplish with traffic like this, and what (if anything) is breaking as a result of it. 

-- Kevin