6to4 status (again)

[Tim Chown]

On 1 Mar 2013, at 14:46, "Brzozowski, John Jason" <jjmb at jjmb.com> wrote:
> Oh btw not everyone will turn their relays off. Someone will try to be a hero. :)
> 
In the early days the hero was SWITCH. But I refer you to Batman on the topic of heroes :)

Anyway, it would be great to get a list of, as Brian puts it, 'legacy' equipment that is doing this, or of specific applications that may be doing so (e.g. maybe P2P on certain platforms). Any intel from John or elsewhere would be really interesting. 

I know a significant number of Apple Airport Extremes were 'guilty' a few years ago, but updates were made available for that. Whether those were applied automatically or otherwise is another question.

Tim

> On Mar 1, 2013 8:20 AM, "Tim Chown" <tjc at ecs.soton.ac.uk> wrote:
>> On Fri, Mar 1, 2013 at 8:00 AM, Ole Troan <ot at cisco.com> wrote:
>> John,
>> 
>> > Ole we actually have experience that tells us it would be bad if we turned our relays.  Some streaming service experience is already not optimal over 6to4 using our relays largely related to the protocol not the relays themselves.  Turning ours down would result in the use of a single 6to4 relay on someone else's network.  Further this relay is hosted by a university.  For now we think it makes more sense to keep our running and encourage client side disablement until there is ~0 bits over 6to4.
>> 
>> yep, I understand the choice and what bind you're in.
>> my hope was that everyone, including the university would stop their 6to4 public relays.
> 
> Well that university should quickly spot the 'DoS' that would suddenly hit it, and also turn the relay service off.
> 
> The whole turn-off could ripple through the net in a couple of weeks, with luck :)
> 
> The question really is how many systems are using 6to4 by choice? If it's an issue with address selection where native IPv4 and 6to4 exist, then that should be fixed, else the relays will always be needed.  
> 
> The geeks who want IPv6 can surely use tunnel brokers.
> 
> Tim
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20130301/3cde822a/attachment-0001.html