6to4 status (again)

[Brzozowski, John Jason]

We have also seen Netflix over 6to4 which I am sure works well.


On Tue, Feb 26, 2013 at 8:14 AM, Kevin Day <kevin at your.org> wrote:

>
> On Feb 26, 2013, at 6:25 AM, "Brzozowski, John Jason" <jjmb at jjmb.com>
> wrote:
>
> "in our observation, 50-80% of traffic in 6to4 relay is {coming from,
> going to} Teredo."
>
> Last I checked I believe this was also the case for us.
>
>
>
> I did some simple monitoring of traffic over the last 12 hours to try to
> determine what was so much bandwidth. With the exception of probing deeper
> to see what ISC's name server was replying with, I was looking at headers
> only not packet contents.
>
> Right now the average incoming data rate (v4 and v6) is approximately
> 350mbps. It seems to boil down to:
>
> 1) What looks like DNS amplification attacks. For example, I'm
> seeing 2001:4f8:0:2::19 sending replies to a 6to4 address that look like an
> ANY response for something in the isc.org domain, which is returning
> large RRSIG results. Each result is ~4K spread across a bunch of packets.
> I'm guessing 6to4 is desirable for amplification attacks because of the
> additional overhead of 6to4 making the amplification greater. The v4
> addresses these replies are going to seem to be all within a few /16 and
> /17 sized blocks, with the bottom 15-16 bits randomized. This is about
> 50mbps worth total.
>
> 2) HTTP traffic, going to v6 addresses in popular destinations like
> Facebook and Google's IP space. Another 50mbps or so. A small number of
> unique endpoints doing this, but they're moving a lot of data somehow.
>
> 3) A whole lot of ICMP echoes/replies. Another 10mbps worth.
>
> 4) Very little traffic to/from teredo space. Maybe 5mbps worth.
>
> The remaining ~235mbps is not easily identifiable. If I had to guess it's
> Bittorrent, but very little interaction with Teredo.
>
> Excluding the spraying of addresses in #1, I'm seeing about 3000 unique
> endpoints over a 60 second window.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20130226/5d003948/attachment-0001.html