6to4 status (again)

[Martin Millnert]

On Tue, 2013-02-26 at 07:24 -0500, Brzozowski, John Jason wrote:
> We likely not turn our relays down until the traffic decreases
> significantly.

John,

Are your relays announced to peers or limited for your own customers?

It's the former case which is difficult to manage of these two.

IMO, running a node in this case with rate-limiting is wrong. There may
be other relays with capacity available. If you're considering, like
Kevin, rate-limiting, it's better to stop announcing (to peers) IMO.

> 
> On Mon, Feb 25, 2013 at 7:23 PM, Martin Millnert <martin at millnert.se>
> wrote:
>         Hi Kevin,
>         
>         On 25 feb 2013, at 22:48, Kevin Day <kevin at your.org> wrote:
>         
>         >
>         > I know this was brought up in November, but I didn't see
>         much of a consensus…
>         >
>         > We run one of the public 6to4 relays. Lately traffic to it
>         has been growing very rapidly and I'm really not sure why.
>         Other people shutting their public relays down?
>         
>         
>         Maybe.
>         
>         > More AAAA records are making more people fall back to 6to4?
>         
>         
>         Unlikely, tunnels aren't used much for http, there aren't that
>         many single-stacked high-volume IPv6-sites out there.
>         
>         > Idiots using it for DDoS?
>         
>         
>         Unlikely.
>         
>         >
>         > For most of 2012 the usage averaged about 50-100mbps, but
>         lately we're seeing sustained levels of 500mbps-900mbps. I'd
>         rather not deploy 10GE on our 6to4 box just to handle the
>         traffic growth.
>         
>         
>         A low-hanging fruit, so to speak, of an explanation, is that
>         other networks' preference towards your relays in BGP has
>         increased. That, or latency-improvements of your relay, are in
>         my experience the two major sources of step-shift changes of
>         relaying throughput.
>         
>         >
>         > Has anyone here looked at public 6to4 usage recently and
>         seen similar trends?
>         
>         
>         Not recently, but a considerable time ago, and then i found
>         that 98%+ of the throughput of a 6to4 and teredo-relay I ran
>         was simply nothing more than a rendezvous point between the
>         two tunneling protocols.
>         Oh, and AAAA:s preferred in dual-stack scenarios by either are
>         insignificant.
>         DHT-clouds and Bittorrent-trackers however handle quite a bit
>         of IPv6-nodes, assisted by large cable companies and similar's
>         DPI bandwidth throttling boxes not handling the overlay
>         protocols.
>         
>         >
>         > Part of me is thinking we should just rate limit the box to
>         something more reasonable. While it's still running, it'll be
>         slow enough that hopefully people will move to a better
>         transitional technology. My fear is that it will cause more
>         "v6 sucks, it's so slow" and people shut it off without
>         looking at why.
>         
>         
>         Honestly, draw that argument to its conclusion and don't get
>         caught in an inverse of the to me familiar stale mate of
>         swedish public alcohol politics discussing the pros and cons
>         of adding saturday opening hours of the state owned alcohol
>         distribution monopoly(*).
>         
>         I.e., turn it off and do not look back. :-)
>         Look ahead.
>         
>         Individuals shutting off 6to4 has very little bearing on the
>         bottom line, i think.
>         
>         Best regards,
>         Martin
>         * "it's a state operated monopoly so that people don't drink
>         themselves to death [which people do if the alcohol shop is
>         open, apparently], but it would be convenient if it's open a
>         bit more"
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20130226/102a7e0c/attachment.sig>