Subject: 6to4 to Historic (ipv6-ops@cluenet Re: 6to4 in Internet aaaa records)

From: Jeroen Massar <[email-masked]>
Date: Fri, 03 Oct 2014 06:57:20 -0400

As some .gov agency is reminding us[1], it might be time to finally lay
6to4 to rest by making it historic.

Can we revive:
 http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-05

and finally make it into a BCP, marking 6to4 historic.

That way, we can also get operators to wind down on 2002::/16 relays and
give a clear signal that folks really should have native in 2014.

Greets,
 Jeroen

[1] www.azdes.gov = 2002::cf6c:8846

-------- Forwarded Message --------
Subject: Re: 6to4 in Internet aaaa records
Date: Fri, 03 Oct 2014 17:06:27 +1300
From: Brian E Carpenter <[email-masked]>
CC: Jeroen Massar <[email-masked]>, IPv6 operators forum
<[email-masked]>

[..]
>> and of course also:
>>  http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-05
>>  (though that technically expired).

3 years ago that seemed premature. With recent progress in real IPv6,
I'm wondering whether it isn't time to revive it. If so it should be
changed to be a BCP that says "Don't do this" and also makes
the proposed standard drafts Historic.

But we do hear persistently that there are happy hobbyist and peer to peer
users of 6to4. Using it offer web service for the Arizona Department of
Economic Security is so wrong, though.

---

From: Brian Haberman <[email-masked]>
Date: Fri, 03 Oct 2014 07:55:34 -0400

As a process point, we do not need a draft to move an RFC to Historic.
Please review this IESG statement:

http://trac.tools.ietf.org/group/iesg/trac/wiki/DesignatingAsHistoric

Regards,
Brian

On 10/3/14 6:57 AM, Jeroen Massar wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 03 Oct 2014 09:02:36 -0400

> http://trac.tools.ietf.org/group/iesg/trac/wiki/DesignatingAsHistoric

Yes, but it is good to have a background reason for historical purposes.

Greets,
 Jeroen

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 03 Oct 2014 09:06:00 -0400

On 2014-10-03 07:05, Erik Kline wrote:
> One concern I remember from one of the most vocal opponents at that time
> was that deprecation might cause code to get deleted from codebases

Why would that be bad?

Code that is not used and could possibly provide a path to some kind of
exploit/abuse/unknown use is good to disappear.

One of the many things that the LibreSSL folks are doing to OpenSSL.

> or at the very least bitrot (with various patches rejected sited IETF
> deprecation).

The only acceptable patch is in those cases a patch that
removes/deprecates the support.

> I believe this person either had or knew of one or more
> private uses of 6to4 that would therefore likely suffer.

"Private" means "local", thus do not require anything on the rest of the
Internet. Also it means that they can set up 6in4 based tunnels or use
ISATAP.

Unless that "person" provides a lot more details and reasoning, does it
matter?

Greets,
 Jeroen

---

From: Brian Haberman <[email-masked]>
Date: Fri, 03 Oct 2014 09:08:43 -0400

Hi Jeroen,

> Yes, but it is good to have a background reason for historical purposes.

Sure.  And that is what the status-change documents do.  They are not as
verbose as another RFC, but that is usually a good thing.

Take a look at some examples...

https://datatracker.ietf.org/doc/rfc-status-changes/

>>>>>  http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-05

Yeah, the content of section 3 of that draft can very easily be put in a
status-change document for historical purposes.

Regards,
Brian

---

From: Erik Kline <[email-masked]>
Date: Fri, 3 Oct 2014 20:05:01 +0900

One concern I remember from one of the most vocal opponents at that time
was that deprecation might cause code to get deleted from codebases, or at
the very least bitrot (with various patches rejected sited IETF
deprecation).  I believe this person either had or knew of one or more
private uses of 6to4 that would therefore likely suffer.

I was in favor of deprecation at that time, but I could understand the
point being made.

---

From: Alejandro Acosta <[email-masked]>
Date: Fri, 03 Oct 2014 08:53:40 -0430

Hi List,
  The first time I read about this idea I did not pay attention but now
I would like to say that I agree with this.
  The reason I support this idea is that for many many years a lot of
transition mechanisms have been created generating several doubts to
service providers. Deprecating 6to4 will give direct and indirect
reasons to service providers to move to native IPv6.
 
Best regards,

Alejandro,

---

From: Mark Andrews <[email-masked]>
Date: Sat, 04 Oct 2014 00:05:19 +1000

> reasons to service providers to move to native IPv6.

ISP's are already moving.  I seriously doubt that moving 6to4 to
historic will make one iota of difference.  All it will do is
make it more painful for those that rely on it.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 03 Oct 2014 16:06:16 +0200

> exploit/abuse/unknown use is good to disappear.

It would be good to document cases where that happened.

Here something along these lines happened recently with the -brand- CLI 
not specifying the IPv4 dst address, followed by "invalid memory 
action", and then by all outgoing IPv6 packets going encapsulated to 
random IPv4 addresses.  Not only  it could have been considered 
legitimately as an attack by the receivers, but had a geo-political 
dimension on it when localized on certain regions of a map.

On another hand, for whatever is worth, at my local setting IPv6 as 
'6to4' works just fine in 2014 and maybe in 2015 there would be reason 
to move to native, and even more so if 6to4 service is not maintained.

Alex

---

From: Tim Chown <[email-masked]>
Date: Fri, 3 Oct 2014 15:22:22 +0100

> make it more painful for those that rely on it.

A problem is we simply don’t know who relies on it.

The Google stats have 6to4/Teredo traffic at 0.01%, and native approaching 5%.  

But what I assume that Google figure doesn’t show is 6to4 to 6to4 traffic, which is the mode in which it works well, rather than where it depends on the highly problematic relays.

Tim

---

From: Michael Sweet <[email-masked]>
Date: Fri, 03 Oct 2014 12:06:23 -0400

FWIW, as an implementor I incorporated changes into CUPS to prevent the use of 6to4 back in October of 2005 (9 years ago), mainly because of the issues identified in:

    http://tools.ietf.org/html/rfc3964
    ftp://ftp.itojun.org/pub/paper/draft-cmetz-v6ops-v4mapped-api-harmful-01.txt

> On Oct 3, 2014, at 10:06 AM, Alexandru Petrescu <[email-masked]> wrote:
> 
> Here something along these lines happened recently with the -brand- CLI not specifying the IPv4 dst address, followed by "invalid memory action", and then by all outgoing IPv6 packets going encapsulated to random IPv4 addresses.  Not only  it could have been considered legitimately as an attack by the receivers, but had a geo-political dimension on it when localized on certain regions of a map.
> 
> On another hand, for whatever is worth, at my local setting IPv6 as '6to4' works just fine in 2014 and maybe in 2015 there would be reason to move to native, and even more so if 6to4 service is not maintained.
> 
> Alex
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 04 Oct 2014 11:56:34 +1300

> But what I assume that Google figure doesn’t show is 6to4 to 6to4 traffic, which is the mode in which it works well, rather than where it depends on the highly problematic relays.

Exactly. That's why I think we actually need a BCP (probably in v6ops)
rather than a simple s/Proposed Standard/Historic/.

The motivation here is damage prevention, and that cuts both ways.

   Brian

> .

---

From: Tore Anderson <[email-masked]>
Date: Sat, 04 Oct 2014 11:02:26 +0200

* Tim Chown

> The Google stats have 6to4/Teredo traffic at 0.01%, and native

When we realised that the IETF wasn't ready to deprecate 6to4, we went
straight to the software vendors instead, who *did* listen and took the
necessary steps to deprecate/disable it in their products. So we
fortunately succeeded in killing it without the IETF's help.

In all likelihood, the 0.01% constitute the long trail of not upgraded
software and operating systems. They'll go away eventually; I doubt that
reviving the 6to4-to-historic draft would accelerate the process.

Marking 6to4 as historic would appropriately document current
operational reality, though. I suppose that would have some value in
itself, so I'd support doing so. That said, I doubt marking it as
historic will prevent people from doing stupid things, like the
«www.azdes.gov. IN AAAA 2002::cf6c:8846» example that started this
thread. (If you look closely, you'll see that this isn't even a valid
6to4 address.)

> But what I assume that Google figure doesn’t show is 6to4 to 6to4
> traffic, which is the mode in which it works well, rather than where
> it depends on the highly problematic relays.

I'm guessing that it would almost exclusively be BitTorrent. If I'm
right about that, I don't think it would count as «relying on it»
because of the way BitTorrent works; taking away 6to4 wouldn't break
BitTorrent in the slightest.

Tore

---

From: Jeroen Massar <[email-masked]>
Date: Sat, 04 Oct 2014 11:26:14 +0200

> reviving the 6to4-to-historic draft would accelerate the process.

It would indeed not, but it would give a signal as then it is
"officially" gone, especially the .govs understand that.

> thread. (If you look closely, you'll see that this isn't even a valid

(Can't fix PEBKAC :)

> BitTorrent in the slightest.

I would assume the same, especially as RFC3484 and Happy Eyeballs caused
6to4 to be used in very few circumstances.

Greets,
 Jeroen

---

From: Sander Steffann <[email-masked]>
Date: Sat, 4 Oct 2014 11:59:01 +0200

Hi,

> itself, so I'd support doing so.

+1.

I still have people in my training classes that think 6to4 is a great idea. When I tell them why they shouldn't depend on 6to4 I sometimes get the reply: "but it's an official internet standard, we should just be able to use it!". And I'm sure that they're not the only ones that prefer 'standards' over common sense.

Good documentation of current operational reality is important.

Cheers,
Sander

---

From: Randy Bush <[email-masked]>
Date: Sat, 04 Oct 2014 19:27:30 +0900

ok.  i am confused.  what is 6to4?  i thought we were supposed to be
going from 4 to 6.  this ietf place is pretty crazy.

randy

---

From: Erik Nygren <[email-masked]>
Date: Sat, 4 Oct 2014 14:24:30 -0400

On Sat, Oct 4, 2014 at 5:59 AM, Sander Steffann <[email-masked]> wrote:

> I still have people in my training classes that think 6to4 is a great
> idea. When I tell them why they shouldn't depend on 6to4 I sometimes get
> the reply: "but it's an official internet standard, we should just be able
> to use it!". And I'm sure that they're not the only ones that prefer
> 'standards' over common sense.
>

+1.

I run into the same issue.

Similarly, it would be good to be able to officially confirm/communicate
to people that standing up IPv6 networks do not need to run 6to4 anycast
relays.
Given the amount of complexity introduced while we're in the dual-stack
world,
anything we can do that officially reduces that complexity is also valuable.

     Erik

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 05 Oct 2014 08:16:50 +1300

> I run into the same issue.

There's another issue here that I see from time to time in under-informed
discussion forums such as www.theregister.co.uk/ :

Some people believe that anybody can get an IPv6 address by sticking
their IPv4 address after a magic prefix. ::/96 is a popular choice
for that magic prefix, and judging by the azdes.gov some people
believe that 2002::/96 is equally magic.

Killing that meme would help quite a bit.

That said, I'll repeat that I think a formal deprecation is
now reasonable, but it needs a bit more logic in it than just
declaring several RFCs Historic.

For example, it would not help anybody to switch off correctly
working return 6to4 relays (i.e. boxes that announce 2002::/96).
On the other hand, if all forward relays (boxes that announce
192.88.99.1) were switched off, Anycast 6to4 would cease working
immediately and the resulting problems would vanish.

In fact, it is really only RFC 3068 that needs deprecating,
because that is where the damage comes from. Peer to peer
6to4 doesn't hurt anybody afaik.

> to people that standing up IPv6 networks do not need to run 6to4 anycast

s/do not need/SHOULD NOT/

   Brian

> ------------------------------------------------------------------------
>

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sat, 4 Oct 2014 18:31:20 -0700

----- Original Message -----
> From: Randy Bush <[email-masked]>
> To: IPv6 Deployment Prevention <[email-masked]>
> Cc: 
> Sent: Saturday, 4 October 2014, 20:27
> Subject: Re: 6to4 to Historic (ipv6-ops@cluenet Re: 6to4 in Internet aaaa records)
> 

It was a way for people like me for many years who only had IPv4 at home could get a IPv6 prefix and IPv6 Internet access without having to ask anybody. Configured HE tunnels were/are great, however they didn't provide as optimal forwarding as 6to4 did (my 6to4 relay was only around 1000 miles from me here in Australia, compared to overseas somewhere for the HE tunnel end-point ...)

---

From: Roman Czyborra <[email-masked]>
Date: Sat, 4 Oct 2014 08:26:03 +0200

<sarcasm>Yeah let us move all RFCs to historic that are not by default
turned on in Microsoft Excel.

One historic draft reminded us that a subset of the following techniques
are either not visible on Oettinger's desktop or generated unforeseen
insecurities to somebody and therefore obsolete.

So let us just outlaw the proposed standard technique introduced in 1998's
http://tools.ietf.org/html/rfc2460 for its fringe adoption after a decade
and the so-called internet technique introduced in 1981's
http://tools.ietf.org/html/rfc791 for its apparent social issues.

Once we detach from that 32bit|128bit stupidity to we will no longer
receive such nonsense:

Date: Fri, 03 Oct 2014 06:57:20 -0400
From: Jeroen Massar <[email-masked]>
Organization: http://www.massar.ch/net/

<real>Do the speed and security advantages of 2400:: no longer suffice to
outphase 0.0.0.0 and 2002:: so we need to actively wreck and stress
everything?  Or does 2002:: endanger out profit margins?

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 6 Oct 2014 14:59:48 +0900

Wow, I haven't seen such a negative email in quite a long time.

On Sat, Oct 4, 2014 at 3:26 PM, Roman Czyborra <[email-masked]> wrote:

> Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1900:3001:11::2c])
> 	by new.woffs.de (8.14.4/8.14.4/Debian-4) with ESMTP id s93Avm7Q022176
> 	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO)
> 	for <[email-masked]>; Fri, 3 Oct 2014 12:57:50 +0200
> Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101])
>  (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
>  (No client certificate requested)
>  by ietfa.amsl.com (Postfix) with ESMTPS id 621311AD034
>  for <[email-masked]>; Fri,  3 Oct 2014 03:57:30 -0700 (PDT)
> Received: from kami.ch.unfix.org
>  (173-10-186-209-BusName-washingtonDC.hfc.comcastbusiness.net
>  [173.10.186.209])
>  (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
>  (No client certificate requested) (Authenticated sender: jeroen)
>  by bastion.ch.unfix.org (Postfix) with ESMTPSA id BD0A110069CE3;
>  Fri,  3 Oct 2014 10:57:25 +0000 (UTC)
> Message-ID: <[email-masked]>

---

From: Eliot Lear <[email-masked]>
Date: Mon, 06 Oct 2014 13:44:28 +0200

Hi,

> 6to4 doesn't hurt anybody afaik.

Forgive me for maybe having missed it, but is there a willing draft
author?  I know Ole wrote the original referenced document...

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 07 Oct 2014 08:24:17 +1300

> author?  I know Ole wrote the original referenced document...

I would be willing to work on this with Ole. But it would be nice
to get some actual facts about residual peer-to-peer usage. (We
already know that client-to-server usage of anycast 6to4 is
falling off.)

    Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 6 Oct 2014 21:46:17 +0200 (CEST)

On Tue, 7 Oct 2014, Brian E Carpenter wrote:

> I would be willing to work on this with Ole. But it would be nice to get 
> some actual facts about residual peer-to-peer usage. (We already know 
> that client-to-server usage of anycast 6to4 is falling off.)

My guess is that the best people here to ask would be the IX operators who 
do sFlow analysis, I don't see how else you could analyse IPv4 proto 41 
traffic and count the ratio of traffic that has both src and dst addresses 
in the 2002::/16 within them as opposed to other traffic.

Because that's what we're talking about, right?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 6 Oct 2014 21:56:28 +0200 (CEST)

On Mon, 6 Oct 2014, Mikael Abrahamsson wrote:

> My guess is that the best people here to ask would be the IX operators 
> who do sFlow analysis, I don't see how else you could analyse IPv4 proto 
> 41 traffic and count the ratio of traffic that has both src and dst 
> addresses in the 2002::/16 within them as opposed to other traffic.

I asked around, and at least one IX doesn't look beyond L2 headers with 
their sFlow, so that won't help.

Basically, I don't see how we can easily monitor this without some 
operators giving this to us, and that might just capture a few reagions, 
and might not give a global view.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 05 Oct 2014 14:20:13 -0300

Hi, Brian,

> believe that 2002::/96 is equally magic.

Question: Any ideas of what's the reasoning behind this belief?

-- FWIW, When measuring IPv6 addresses from public-facing servers, I
found many instances of these... but never got to do much
analysis/guesswork regarding where this "assumption" was coming from.

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Brian Haberman <[email-masked]>
Date: Mon, 06 Oct 2014 16:44:19 -0400

> Question: Any ideas of what's the reasoning behind this belief?

IPv4-compatible addresses described in RFC 1884.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 07 Oct 2014 11:08:22 +1300

On 07/10/2014 08:56, Mikael Abrahamsson wrote:
>> who do sFlow analysis, I don't see how else you could analyse IPv4
>> proto 41 traffic and count the ratio of traffic that has both src and
>> dst addresses in the 2002::/16 within them as opposed to other traffic.
> 

Right. We'd actually need to get a set of IPv4 pcap traces from several
IXes to do this. I will ask my local expert on traces but I'm not
too optimistic.

    Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 7 Oct 2014 08:28:37 +0200 (CEST)

On Tue, 7 Oct 2014, Brian E Carpenter wrote:

> IXes to do this. I will ask my local expert on traces but I'm not too 
> optimistic.

I agree. I also think that we should give guidance that in more and more 
NAT44(4):ed world, even p2p 6to4 doesn't work. So I see no downside in 
making 6to4 historic, at least I hope this will stop new implementations 
of 6to4 for reasons that the implementor doesn't know about 6to4 state of 
affairs on the common Internet. If they still choose to implement it, 
that's fine, but at least that'll be a more informed decision.

So can't we just revive 
https://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-05 and see 
if there is consensus? It was a good idea in 2011, it's an even better 
idea in 2014.

---

From: Carlos Friacas <[email-masked]>
Date: Tue, 7 Oct 2014 08:09:04 +0100 (WEST)

Hi,

>> itself, so I'd support doing so.

+1 too.

We ran a 6to4 relay at some point along the way.
It was shutdown a while ago, and nobody complained so far.

However, i still do see 27 2002::/16 objects and 32 192.88.99.0/24 objects 
at the RIPEdb...

> idea.

You still get people at your classes that think NAT and CGN are great 
ideas ? ;-)

> When I tell them why they shouldn't depend on 6to4 I sometimes get 
> the reply: "but it's an official internet standard, we should just be 
> able to use it!". And I'm sure that they're not the only ones that 
> prefer 'standards' over common sense.
>

Completely agree. Cleanup.

Cheers,
Carlos

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Oct 2014 08:37:52 +1300

On 07/10/2014 19:28, Mikael Abrahamsson wrote:
>> Right. We'd actually need to get a set of IPv4 pcap traces from
>> several IXes to do this. I will ask my local expert on traces but I'm
>> not too optimistic.
> 
> NAT44(4):ed world, even p2p 6to4 doesn't work. 

This is indeed discussed in RFC 3056 to some extent, although NAT44
was quite rare then.

> So I see no downside in
> of 6to4 for reasons that the implementor doesn't know about 6to4 state
> of affairs on the common Internet. If they still choose to implement it,

(which was already the intention of RFC 6343 of course).

> if there is consensus? It was a good idea in 2011, it's an even better

I have the xml2rfc source and (with Tore's agreement of course) will
update it soon.

   Brian

---

From: "Dale W. Carder" <[email-masked]>
Date: Sat, 11 Oct 2014 01:54:07 -0500

> fortunately succeeded in killing it without the IETF's help.

Many public relay operators also joined in and terminated service
in 2011 due to draft-ietf-v6ops-6to4-to-historic, including our relay
which at its peak was likely among the most heavily used in North America.  

Today, my route to 192.88.99.1 is in Australia (209ms) and nobody cares.

6to4 was elegantly sunsetted by implementations of rfc6724 and happy 
eyeballs despite draft-ietf-v6ops-6to4-to-historic expiring.

Dale

---

From: Roger Jørgensen <[email-masked]>
Date: Sat, 11 Oct 2014 09:53:58 +0200

> Question: Any ideas of what's the reasoning behind this belief?

I've heard it several places over the year and I guess it's lack of
knowledge, they don't understand (or want to understand) how things
work. That people do write it out as shown bellow don't help

"IPv6 address is calculated from IPv4 (2002:192.168.100.1::/48) "
Page 9 on https://www.ripe.net/ripe/meetings/regional-meetings/dubrovnik-2011/presentations/IPv6_Transition_Mechanisms_Ripe_07092011_v1.2.pdf

I expected to find 2002::IPv4Address in clear text on
technet.Microsoft but they seem to have not written it anywhere, only
IPv4 and then the correct representation of it on 2002:: format. Very
good:)

-- 

Roger Jorgensen           | ROJO9-RIPE
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 12 Oct 2014 08:25:20 +1300

> which at its peak was likely among the most heavily used in North America.  

Many != all though.

> eyeballs despite draft-ietf-v6ops-6to4-to-historic expiring.

Yes, but there are still certainly millions of people running XP and the
like with old browsers, and we simply don't know how many of them are
still suffering as a result (especially if they have to go via Australia
to discover black holes). So I don't think we can assert that nobody cares.
Therefore, I think it's useful now to take the next step. (It's in
Ole's inbox.)

   Brian

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 13 Oct 2014 17:17:16 +0200

Hello,

This is an end user experience, at the edge of the network.

The reasons I invoke at our local site to migrate to native IPv6 from 
currently 6to4 are the following:

- we currently depend on the well functioning of a publicly available 
6to4 Relay.  This Relay has no commitment of service whatsoever, it can 
turn down anytime.

- all our  IPv6 traffic is subject to scrutiny at these Relays.

- we depend extensively on DNSv6 of google, being incapable of creating 
our own full DNSv6, because impossible to offer reverse resolution.

- we may risk being considered as spammers as some email spam filters on 
some servers try reverse resolution before accepting emails (IIRC).

- the IP paths IPv6 packets take outwards our setting differ 
systematically from the in-bounds. (triangular routing is not an 
exception but the norm).  This has negative impact on some applications.

- strong security risks have been identified with a particular 6to4 
implementation in a particular brand.  It led to false positives on 
sensitive traffic identification.

Alex

---

From: "Dale W. Carder" <[email-masked]>
Date: Mon, 13 Oct 2014 16:40:34 -0500

Thus spake Brian E Carpenter ([email-masked]) on Sun, Oct 12, 2014 at 08:25:20AM +1300:
> like with old browsers

XP has ipv6 off by default, no?  I think the only users who would be
materially affected might be apple <= 10.6 who only use safari as their
browser and have a home router that will send 6to4 RA's, but can't/won't 
do 6rd when available.  So, maybe my mom ;-)

> and we simply don't know how many of them are

To be clear, my "nobody cares" was in reference to my ~1M end-users, with
zero trouble tickets that resulted from disabling our local relays and bgp 
choosing the one 209ms away (looks like anyone who localpref's prefixes 
from as11537 might also choose this particular relay).

My guess without even looking at the data is that the remaining 6to4 
traffic that one would see at an IX would be bittorrent.  If possible it
may be better to get clarification from google et. al as to what browser
strings they are seeing?

Dale

---

From: Mark Andrews <[email-masked]>
Date: Tue, 14 Oct 2014 10:06:52 +1100

> may be better to get clarification from google et. al as to what browser

Also while gatewaying packets on the other side of the world is not
optimal, it does work.  Most things don't care about a extra 200 odd
ms.