Subject: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

From: [email-masked]
Date: Sun, 16 Nov 2014 11:00:01 -0800

This is to initiate a two week working group last call of
http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic.  
Please read it now. If you find nits (spelling errors, minor suggested
wording changes, etc), comment to the authors; if you find greater
issues, such as disagreeing with a statement or finding additional
issues that need to be addressed, please post your comments to the
list.

We are looking specifically for comments on the importance of the
document as well as its content. If you have read the document and
believe it to be of operational utility, that is also an important
comment to make.

---

From: Philip Homburg <[email-masked]>
Date: Sun, 16 Nov 2014 21:11:43 +0100

>believe it to be of operational utility, that is also an important

First a minor comment. The document states a couple of times that it
updates RFC 6343. Maybe my reading was too sloppy, but I couldn't find
an explicit statement on how RFC 6343 was updated.

But a more fundamental comment. I'd like this document to be not published at
all. At least not until 6to4 has died of natural causes. 

RFC 6343 clearly states what is wrong with 6to4. In that sense most of the
text in this RFC is superfluous. 

Yes, according to all measurements, 6to4 is broken. However in individual
cases it may work. Last time we had this discussion, I did verify that for
me 6to4 resulted in a good IPv6 experience. This time I couldn't be bothered.

>From the discussions, it is clear that a few people really use 6to4 and want
to continue using it.

So in my opinion, this draft doesn't add anything of value. And we should
remain silent about 6to4 until it has actually died.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Nov 2014 11:38:15 +1300

Philip,

Please clarify whether you are referring specifically to anycast
6to4 in your objection. Following the discussion in Honolulu,
that is all the draft proposes to deprecate.

Regards
   Brian

On 17/11/2014 09:11, Philip Homburg wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Philip Homburg <[email-masked]>
Date: Mon, 17 Nov 2014 09:51:35 +0100

>that is all the draft proposes to deprecate.

The current draft deprecates RFC 3068. So yes, I think that RFC should
continue to exist until essentially nobody is using it anymore.

---

From: Keith Moore <[email-masked]>
Date: Mon, 17 Nov 2014 12:37:49 -0500

> continue to exist until essentially nobody is using it anymore.
You do realize that the RFC will "continue to exist" regardless of 
whether it's deprecated?   RFCs never go away.

Keith

---

From: Philip Homburg <[email-masked]>
Date: Mon, 17 Nov 2014 19:37:13 +0100

>whether it's deprecated?   RFCs never go away.

I should have worded that better. And it is more difficult because its
current status is standard track.

In any case, I think it is better to leave the status unchanged. Leave it to
RFC 6343 to describe why it should not be used. And then do nothing until
there are no more relays or something like that. Or until there is no
more IPv4 to transport 6to4 packets in the first place.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Nov 2014 08:49:25 +1300

> more IPv4 to transport 6to4 packets in the first place.

OK, thanks for the clarification. It's for the chairs to say at
the end of the WGLC, but for now the message that the draft
authors got from the meeting was different.

    Brian

---

From: Mark Andrews <[email-masked]>
Date: Tue, 18 Nov 2014 08:23:01 +1100

> authors got from the meeting was different.

This draft does *harm* to the set of people for whom 6to4 anycast
works.  It actively sabotages their working connections by filtering
the routing information required to reach the relay.  It recommends
that 6to4 support be removed from / not added to products making
upgrading existing equipement (harware and software wise) dangerous
for those that have working 6to4 connections.

It is as far as I can see a knee jerk reaction to one person thinking
that 6to4 was as far as they needed to go with IPv6 despite the
original 6to4 rfc stating that native should be used.  Despite other
rfcs pointing out all the faults in 6to4.

I don't support this draft.

I would recommend a draft that recommended that every ISP when they
enable IPv6 native also add a 6to4 relay and inject the anycast
prefix into their IGP.  That they then monitor that relay and
actively contact the 6to4 sources to recommend that they switch to
native IPv6.  That the 6to4 relay stay in place until such time as
the traffic ceases for a period of 12 months.

I would also recommend that ISP's actively look for protocol 41
traffic before enabling CGN's and ensure that their customers have
working non protocol 41 based IPv6 connectivity before the CGN is
enabled or that such customers are numbered out of a block that
does not go through the CGN.

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

---

From: Ole Troan <[email-masked]>
Date: Mon, 17 Nov 2014 13:34:23 -0800

Mark,

> for those that have working 6to4 connections.

who are those people?
since 6to4 depends on 2 3rd party operated relays to function. which outbound relay you use depends on IPv4 routing, which return relay you use depend on IPv6 routing from the perspective of the destination. which means which return relay is used depends on which destination you are communicating with.

it is therefore hard to see  a scenario where 6to4 would work reliably. please refer back to the measurements that Geoff has done. or do you have different measurements?

cheers,
Ole

---

From: Mark Andrews <[email-masked]>
Date: Tue, 18 Nov 2014 09:02:46 +1100

In message <[email-masked]>, Ole Troan writes:
> since 6to4 depends on 2 3rd party operated relays to function. which
> outbound relay you use depends on IPv4 routing, which return relay you
> use depend on IPv6 routing from the perspective of the destination. which
> means which return relay is used depends on which destination you are
> communicating with.

I know how 6to4 works.  I also know how it can be broken.  I know
its disavantages.  Despite all that it works for some people and
this draft is actively trying to harm those people.

> it is therefore hard to see  a scenario where 6to4 would work reliably.
> please refer back to the measurements that Geoff has done. or do you have
> different measurements?

Does Geoffs figure say 0% work?  Just because it does not work for
some (or even many) does not mean that it does not work for all.
Last time I checked 6to4 worked fine for me.

B.T.W. IPv4 has never worked 100% for me in all the years I've been
on the net (since '88).  Demanding 100% success for 6to4 seems to
be a little over the top.  It just has to work for the sites you
want to connect to.  This applies to IPv4, IPv6 native and IPv6
over whatever transition mechanism you have choosen.

Mark

---

From: Keith Moore <[email-masked]>
Date: Mon, 17 Nov 2014 17:18:26 -0500

> since 6to4 depends on 2 3rd party operated relays to function. which outbound relay you use depends on IPv4 routing, which return relay you use depend on IPv6 routing from the perspective of the de…

Isn't the latter true for IP traffic in general?  The fact that the last 
link is a tunnel over IPv4 doesn't change that.

As far as I can tell path asymmetry is the usual case, not the exception.

Even for the IPv4->IPv6 part of the path, the fact that it uses IPv4 
routing doesn't seem like what's broken or what causes problems.  IPv4 
routing works fine most of the time.   However, every RFC 3068 v4->v6 
router effectively having the same IPv4 address - that does cause 
problems for diagnosis, especially from the user end.

> it is therefore hard to see  a scenario where 6to4 would work reliably.
It's also hard to see how the Internet would work reliably.   :)

Seriously, if we're going to discourage use of 6to4, or even just 
discourage use of anycast relays, let's try to be precise about the 
reasons.   New uses of anycast will need to learn from this example, and 
it's important to understand why this particular use of anycast didn't 
work so well.  This document has always had a vindictive flavor to it - 
as if somehow the people who were using 6to4 deserved to be punished for 
daring to work around the fact that their network providers were 
dragging their feet in deploying IPv6.   That's not shedding light on 
anything, and I think RFCs should try to shed light.

Keith

---

From: Ole Troan <[email-masked]>
Date: Mon, 17 Nov 2014 14:49:05 -0800

Keith,

> Isn't the latter true for IP traffic in general?  The fact that the last link is a tunnel over IPv4 doesn't change that.

15-20% black holing is not common for IP traffic in general.
https://labs.ripe.net/Members/emileaben/6to4-why-is-it-so-bad

> Even for the IPv4->IPv6 part of the path, the fact that it uses IPv4 routing doesn't seem like what's broken or what causes problems.  IPv4 routing works fine most of the time.   However, every RFC 3068 v4->v6 router effectively having the same IPv4 address - that does cause problems for diagnosis, especially from the user end.
> 
> Seriously, if we're going to discourage use of 6to4, or even just discourage use of anycast relays, let's try to be precise about the reasons.   New uses of anycast will need to learn from this example, and it's important to understand why this particular use of anycast didn't work so well.  This document has always had a vindictive flavor to it - as if somehow the people who were using 6to4 deserved to be punished for daring to work around the fact that their network providers were dragging their feet in deploying IPv6.   That's not shedding light on anything, and I think RFCs should try to shed light.

I think the draft outlines that quite sufficiently. I'm asking for the people that claim it "works fine for me", to come up with numbers and do the measurements. so far all the measurements we have show that it does not work fine.

sure, a host with happy eyeballs gives a decent user experience anyway, but a host without does not.

cheers,
Ole

---

From: Keith Moore <[email-masked]>
Date: Mon, 17 Nov 2014 18:28:41 -0500

> https://labs.ripe.net/Members/emileaben/6to4-why-is-it-so-bad

Agreed, but what does that have to do with either anycast, or path 
asymmetry?

> I think the draft outlines that quite sufficiently.

I disagree.   The current version is better but it's still incorrect on 
several counts.   (outlined elsewhere)

> I'm asking for the people that claim it "works fine for me", to come up with numbers and do the measurements. so far all the measurements we have show that it does not work fine.

6to4 worked fine for me for many years, where "fine" meant that it 
worked mostly between 6to4 hosts with occasional use to access native v6 
hosts.   I experienced the problem with v6 routing working worse than v4 
routing early on, but changes to the prefix selection algorithm mostly 
fixed that.   It only stopped working fine for me within the past few 
months, for reasons unknown.

The problem with the measurements that you cite is simply that aggregate 
measurements do not do a good job at predicting behavior observed by 
individuals.    If your measurements reveal that in the aggregate, 6to4 
only works X% of the time, that doesn't mean that individual users 
experience anything like that.  It's much more likely that for an 
individual user, 6to4 either works almost all of the time or almost none 
of the time.   And a lot depends on _how_ 6to4 is used.   If you try to 
use it to get to web sites that also have v4 access, you're likely to be 
disappointed.   But if what you want it for is to get to hosts that are 
on v6 but not on v4, you may find that it works very well (as long as 
you're not behind a NAT).

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Nov 2014 13:39:20 +1300

On 18/11/2014 11:49, Ole Troan wrote:
> Keith,
> 
>>>> This draft does *harm* to the set of people for whom
>>>> 6to4 anycast works.  It actively sabotages their
>>>> working connections by filtering the routing
>>>> information required to reach the relay.  It recommends
>>>>  that 6to4 support be removed from / not added to
>>>> products making upgrading existing equipement (harware
>>>> and software wise) dangerous for those that have
>>>> working 6to4 connections.
>>> who are those people? since 6to4 depends on 2 3rd party
>>> operated relays to function. which outbound relay you use
>>> depends on IPv4 routing, which return relay you use
>>> depend on IPv6 routing from the perspective of the
>>> destination. which means which return relay is used
>>> depends on which destination you are communicating with.
>> Isn't the latter true for IP traffic in general?  The fact
>> that the last link is a tunnel over IPv4 doesn't change
>> that.
> 
>> Even for the IPv4->IPv6 part of the path, the fact that it
>> uses IPv4 routing doesn't seem like what's broken or what
>> causes problems.  IPv4 routing works fine most of the time.
>> However, every RFC 3068 v4->v6 router effectively having
>> the same IPv4 address - that does cause problems for
>> diagnosis, especially from the user end.
>> 
>> Seriously, if we're going to discourage use of 6to4, or
>> even just discourage use of anycast relays, let's try to be
>> precise about the reasons.   New uses of anycast will need
>> to learn from this example, and it's important to
>> understand why this particular use of anycast didn't work
>> so well.  This document has always had a vindictive flavor
>> to it - as if somehow the people who were using 6to4
>> deserved to be punished for daring to work around the fact
>> that their network providers were dragging their feet in
>> deploying IPv6.   That's not shedding light on anything,
>> and I think RFCs should try to shed light.
> 
> I think the draft outlines that quite sufficiently. I'm
> asking for the people that claim it "works fine for me", to
> come up with numbers and do the measurements. so far all the
> measurements we have show that it does not work fine.
> 
> sure, a host with happy eyeballs gives a decent user
> experience anyway, but a host without does not.

The users who will suffer if the anycast servers vanish
are those with the old RFC 3484 policy table (which prefers
6to4 above IPv4) *and* without Happy Eyeballs *and* with a good
working anycast relay *and* who access sites that have a good
working return relay. Those people will see new black holes
unless they disable IPv6.

I'm pretty sure that will amount to fewer than 100k users, from
the Google statistics. Of course, inconveniencing up to 100k
people is something to think about carefully. (Somebody
suggested at an earlier stage defining a sunset date - is that
worth considering? 6/6/2015 or something.)

The question in my mind is whether the words we put in the
proposed BCP will really be the cause of change, or simply
endorse what ISPs are doing already.

  Brian

---

From: Keith Moore <[email-masked]>
Date: Mon, 17 Nov 2014 20:37:45 -0500

On 11/17/2014 07:39 PM, Brian E Carpenter wrote:
> 6to4 above IPv4)*and*  without Happy Eyeballs*and*  with a good
> working anycast relay*and*  who access sites that have a good
Why is it so common to assume these days that Internet usage is about 
"accessing sites"?

I think that many users who suffer will be those who have already 
invested in 6to4 and done what they needed to do to make it work, 
including insisting that their access networks not interfere with 
protocol 41, or filter routes or traffic to relay routers.    Since 
that's a self-selecting group, estimates of its size based on the 
percentage of users for which 6to4 works by accident is probably not 
going to work very well.

None of this would bother me much if there were a suitable replacement.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Nov 2014 16:43:17 +1300

> Why is it so common to assume these days that Internet usage is about

I really think it is the correct assumption for people who are
using anycast 6to4 without knowing it, who are the people most
likely to be mystified if the anycast address stops working.

> percentage of users for which 6to4 works by accident is probably not

No indeed; but I think that the set of people *intentionally
using anycast 6to4* is indeed a very select group, although I
have no idea how to count them.

Personally, if the consensus is to remove the recommendation to
filter the anycast address, I won't be upset - but I doubt if
the eventual BCP will much affect which ISPs decide to filter it
anyway.

>From my personal experience, native IPv6 is the only truly
zeroconf replacement.

   Brian

---

From: Keith Moore <[email-masked]>
Date: Mon, 17 Nov 2014 22:55:05 -0500

> likely to be mystified if the anycast address stops working.

I'd like to assume that, by now, software updates have drastically 
reduced that set of people, and/or minimized the impact on that group 
via inclusion of better address selection and/or happy eyeballs and/or 
6to4 off-by-default.   It seems to me that those using the Internet 
mostly to "access sites" are very unlikely to miss 6to4 unless they're 
still using very old address selection algorithms.
> the eventual BCP will much affect which ISPs decide to filter it

I don't think I'd blame ISPs for filtering such advertisements from 
other networks (especially if those routers turned out to be flaky) but 
by now I'm not sure how much they'd benefit by doing so.
>  From my personal experience, native IPv6 is the only truly

To me, that seems like (at best) the slowest possible path to victory.

(of course, nothing tunneled over IPv4 will ever work as well as native 
IPv4 to reach destinations that have both IPv4 and IPv6 - which is 
generally the metric by which these solutions have been judged.)

Keith

---

From: Doug Barton <[email-masked]>
Date: Mon, 17 Nov 2014 21:48:41 -0800

> Why is it so common to assume these days that Internet usage is about

Because that's what the overwhelming majority of traffic is? Even P2P I 
rarely see 6to4 addresses, although I do see a non-trivial number of 
Teredo addresses ... go figure.

> invested in 6to4 and done what they needed to do to make it work,

Where/who are these users? Are you theorizing, or do you have hard data?

> percentage of users for which 6to4 works by accident is probably not

So is the greater harm to disable an inferior technology that far more 
people are hurt by then helped?

> None of this would bother me much if there were a suitable replacement.

Why do you not believe that intentional tunnels (ala SixSS or HE) are a 
suitable replacement? Way back when there were no other alternatives, 
6to4 may have been a good idea to give people a chance to play with IPv6 
addressing. But that day is long gone, how is recognizing that a bad thing?

Doug

---

From: Keith Moore <[email-masked]>
Date: Tue, 18 Nov 2014 02:04:50 -0500

On 11/18/2014 12:48 AM, Doug Barton wrote:
> Because that's what the overwhelming majority of traffic is?

Perhaps, but it's irrelevant in this case.   Traffic volume is a poor 
proxy for importance.    And for those who find 6to4 valuable today, 
it's not because it lets them get to web sites that are also accessible 
via IPv4.   Most uses of 6to4 are probably not to reach 
publicly-accessible services, because today if you want your service to 
be accessible to the public, you have to support IPv4.

> Where/who are these users? Are you theorizing, or do you have hard data?

I'm theorizing, or extrapolating from my own limited experience. (But 
hard data is misleading at best unless it's relevant and used properly.)

> people are hurt by then helped?

Inferior to what, and for what purpose?

Also, 6to4 hasn't hurt more people than it helped.  Given a 
properly-functioning IPv4 network, 6to4 works reasonably well.

The things that hurt people were:

  * network operators who delayed deployment of IPv6,
  * network operators who blocked protocol 41 traffic,
  * network operators who set up broken relays,
  * the operators who installed NATs and the vendors that promoted them, and
  * applications and stacks that couldn't deal well with multiple active
    network interfaces  with significantly different characteristics
    (which is quite common these days and not at all specific to 6to4).

Blaming 6to4 for those problems is like blaming the canary in a coal 
mine because it stopped singing.

> Why do you not believe that intentional tunnels (ala SixSS or HE) are 
> a suitable replacement?

Because they require explicit configuration, they don't scale well, and 
their routing is often even worse than 6to4's.
(however I'll admit that they have advantages for support and fault 
diagnosis)

> Way back when there were no other alternatives, 6to4 may have been a 
> good idea to give people a chance to play with IPv6 addressing. But 
> that day is long gone, how is recognizing that a bad thing?

As long as we're recognizing bad things, consider adding the above items 
to that list.

Keith

---

From: Gert Doering <[email-masked]>
Date: Tue, 18 Nov 2014 11:41:32 +0100

Hi,

> the traffic ceases for a period of 12 months.

This is *so* decoupled from reality that it would be funny were it not
so sad.

Really.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Gert Doering <[email-masked]>
Date: Tue, 18 Nov 2014 11:52:18 +0100

Hi,

On Tue, Nov 18, 2014 at 02:04:50AM -0500, Keith Moore wrote:
> Also, 6to4 hasn't hurt more people than it helped.  

Now *that* is a very bold statement, which (for the anycast relay 6to4)
really contradicts existing measurements.  But of course with an 
adequate definition of "hurt" and "help", anything can be true.

> Given a 

I think you're talking about peer-to-peer 6to4 (3056) again, no?

For anycast-6to4 (3068) to work well, you need *more* than just a 
properly-functioning IPv4 network - you need properly-function relays
as well.

But I'm sure you know that quite well, and the draft authors already
agreed to not deprecate your RFC, so I wonder what you are argueing for?

Gert Doering
        -- NetMaster

---

From: Sander Steffann <[email-masked]>
Date: Tue, 18 Nov 2014 14:54:53 +0300

Hi Brian,

> endorse what ISPs are doing already.

I am more concerned about end users. When doing IPv6 consultancy I see cases where users want to use 6to4 as their production IPv6 'solution'. They argue that as 6to4 with anycast relays is an internet standard it must be a viable solution for them. Explaining to them that it is not a good idea is sometimes difficult, and usually followed by "we don't believe that it is such a bad solution, otherwise it wouldn't be an Internet Standard".

Now I understand how this works, but there are real users out there that believe "Internet Standard" == "Safely deployable on production networks".

The proposed BCP will be an important message to such users who are not experienced in IPv6. And yes, speaking as an operator it does endorse what ISPs are doing already.

Cheers,
Sander

---

From: Keith Moore <[email-masked]>
Date: Tue, 18 Nov 2014 08:20:18 -0500

> adequate definition of "hurt" and "help", anything can be true.
It doesn't contradict existing measurements, just how those measurements 
are interpreted.   If you interpret those measurements according to an 
assumption that the network is in all respects functioning correctly 
except for 6to4, you'll conclude that 6to4 is the problem.   But that's 
not a valid premise, as we know that the network is not functioning 
correctly in a great many respects.

> properly-functioning IPv4 network - you need properly-function relays

Fair point.

> agreed to not deprecate your RFC, so I wonder what you are argueing for?

Truth.   Or is truth out-of-scope?

More precisely:   I accept that as a practical matter, 6to4 is doomed 
because of the exhaustion of IPv4 address space and increasingly wide 
deployment of carrier-side NAT.   But if we're going to cast blame, 
let's put the blame where it belongs.

Keith

---

From: Ray Hunter <[email-masked]>
Date: Tue, 18 Nov 2014 14:27:23 +0100

> believe it to be of operational utility, that is also an important
Generally I am in favour of this draft.

One substantive point remains open for me.

I don't understand why the advice /Internet service providers SHOULD 
filter out routes to 192.88.99.1./ is going to improve the Internet.

If a route to 192.88.99.1 exists, it is presumably being injected by 
someone providing a working anycast 6to4 relay.

AFAICS Older implementations apparently won't change their behaviour in 
the case of "zero" or "poor" connectivity via anycast 6to4, so filtering 
out of the anycast route doesn't help those users. Newer implementations 
anyway avoid the pitfalls of "zero" or "poor" connectivity via anycast 
6to4 (via updated address selection rules, happy eyeballs etc. etc.), so 
filtering of the anycast route is neutral to them. So the only people 
who would be affected by a filter of the anycast route would presumably 
be any successful 6to4 users out there, and it would presumably make 
their life worse as it would deny them access to a 6to4 relay.

So on balance, IMHO filtering the route to the anycast address 
192.88.99.1 (and thus presumably denying access to a working anycast 
relay) would seem more likely to break something rather than fix it.

-- 
Regards,
RayH

---

From: Gert Doering <[email-masked]>
Date: Tue, 18 Nov 2014 14:28:24 +0100

Hi,

> correctly in a great many respects.

The measurements quite clearly demonstrate that anycasted 6to4 works
*less* well than native IPv4.  This is not assuming IPv4 works 100%.

[..]
> deployment of carrier-side NAT.   

Actually, that might be the doom for peer-to-peer 6to4, but *that* is
totally out of scope.  Anycast 6to4 was broken long before widespread
CGN deployment (actually, CGN should help avoid anycast 6to4 brokenness,
as nodes won't fire up 6to4 if they have no public IPv4 address at all).

> But if we're going to cast blame, 

The blame belongs to a non-workable deployment model for relays - someone
pays, someone else benefits.  This cannot be fixed, unless a central
Internet government is installed that will ensure that everyone provides
a well-maintained 6to4 anycast relay that benefits mostly "everyone else"
(if I have native IPv6, my customers really don't need a 6to4 relay, except
to help those other ISP's customers that do not have IPv6 yet - who pays,
who reaps the befits, again).

Thus, 3068 must go.

Gert Doering
        -- NetMaster

---

From: Sander Steffann <[email-masked]>
Date: Tue, 18 Nov 2014 16:34:39 +0300

Hi,

> *less* well than native IPv4.  This is not assuming IPv4 works 100%.

+1

[..]

> who reaps the befits, again).

+1

It is really sad that the IETF asks for operator input but then discards the input provided by those operators or keeps fighting their input as non-truths.

3068 is causing operational problems
3068 must go

Cheers,
Sander

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 18 Nov 2014 14:36:23 +0100

On 2014-11-18 14:27, Ray Hunter wrote:
[..]
> someone providing a working anycast 6to4 relay.

Even if that route works and that relay works, there is no way to know
if the return path works, or if the 2002::/16 prefix is properly announced.

There is a stack of problems that can be caused.

IMHO, the doc should not say to filter the prefix, but to stop
announcement at all. Better still, forbid anybody from announcing that
prefix. (I wonder how quickly somebody starts using it as their own
private PI anycast prefix ;)

> out of the anycast route doesn't help those users.

If you have a stack that old, you have different problems already.
Advise: let them upgrade.

Also, removing a an interface or route (2002::/16) is typically easy on
those platforms.

> Newer implementations

As anycast 6to4 would be deprecated, that is kind of the point ;)

Peer to peer 6to4 should be fine and unaffected.

Greets,
 Jeroen

---

From: Philip Homburg <[email-masked]>
Date: Tue, 18 Nov 2014 14:42:57 +0100

>*less* well than native IPv4.  This is not assuming IPv4 works 100%.

I doubt that that is true for an IPv6-only target.

---

From: Keith Moore <[email-masked]>
Date: Tue, 18 Nov 2014 08:56:08 -0500

> *less* well than native IPv4.  This is not assuming IPv4 works 100%.
That's not a valid basis for comparison, for several reasons:

  * Of course tunneling v6 over v4 performs worse than native v4, if for
    no other reason than increased packet overhead, lower MTU, and
    likely longer path links.   That was always a given. The problem
    wasn't that 6to4 performed worse than v4, it was that early address
    selection rules were designed with the false assumption that (any
    kind of) v6 would provide at least as good a service as v4.
  * The purpose of 6to4 was never to work better than native v4 (in
    these respects), the purpose was to provide v6 access to users
    without v6 access and to do so in a fashion that required minimal
    configuration.
  * For some definitions of "better", e.g. ability to support p2p
    traffic, tunneled v6 could indeed work better than NATted v4 even
    when both paths were available.

And of course there's still the problem of interpreting those data.   So 
when the measurements showed (for example) protocol 41 blocking, 
concluding that 6to4 was the problem was fairly arbitrary - it was at 
least as valid to conclude that the problem was protocol 41 blocking.   
(Of course broken relays, unfiltered advertisements to relays not 
willing to forward all traffic, and NATs, were also parts of the problem.)

> CGN deployment
Widespread CGN deployment resulting from v4 address space exhaustion is 
the reason 6to4 cannot be fixed, but not the reason 6to4 didn't work 
well for users.

> (actually, CGN should help avoid anycast 6to4 brokenness,

Except that CGN doesn't tend to use RFC 1918 addresses, so existing 6to4 
implementations won't know to disable 6to4 in those conditions.

> pays, someone else benefits.

That's certainly a contributing factor, and one worth documenting. And 
yet, on another level, the Internet already assumes this model, and it 
more-or-less works.   I think the problem is a bit more subtle than 
that: (a) difficulty in fault diagnosis and tracing when using an 
anycast address as a default route, and (b) the belief that, unlike 
ordinary IP service, 6to4 service was not something that operators not 
providing relays needed to concern themselves with.   Thus 6to4 was seen 
as a problem by operators, whereas providing IPv4 connectivity to other 
networks was seen as part of doing business, even though both relied on 
the "non-workable" cost recovery model.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 18 Nov 2014 09:02:52 -0500

> It is really sad that the IETF asks for operator input but then discards the input provided by those operators or keeps fighting their input as non-truths.

Operator input is of course welcome and badly needed.   But that doesn't 
mean that everything said from an operator's point-of-view should be 
accepted without question.   The conditions that led to 6to4 not working 
well were a combination of: design oversights in both 6to4 and IP 
stacks, carrier behavior, local network operator behavior, and hardware 
vendor behavior in promoting NAT.   We don't do anyone a service by 
pretending that any of these weren't contributing to the problem.

Keith

---

From: Philip Homburg <[email-masked]>
Date: Tue, 18 Nov 2014 15:11:52 +0100

>private PI anycast prefix ;)

You are saying that the IETF (and the operator community in general) are
now in the business of breaking people's connections?

Current users of 6to4 do no harm. The send packets to relays, they may
receive packets from other relays. No big deal. 

I'm surprised at how insistent people are at breaking that.

Next up, let's block access to tcp port 80 because it is not secure.

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 18 Nov 2014 14:15:54 +0000

> This is *so* decoupled from reality that it would be funny were it not

+N, where N is large.

Nick

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 18 Nov 2014 15:37:52 +0100

> now in the business of breaking people's connections?

Is anycast 6to4 working anywhere? :)

> Current users of 6to4 do no harm.

They do no harm as their packets go nowhere.

The harm is done in support calls at various ISPs.

> The send packets to relays, they may

They send packets, reception is typically spotty.

> I'm surprised at how insistent people are at breaking that.

Possibly as lowering support calls and lowering brokeness that gives
IPv6 a bad name is a good thing?

> Next up, let's block access to tcp port 80 because it is not secure.

HTTP unfortunately is not a new or broken protocol, but did you see:

https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/

Greets,
 Jeroen

---

From: Philip Homburg <[email-masked]>
Date: Tue, 18 Nov 2014 15:43:34 +0100

>Is anycast 6to4 working anywhere? :)

Yes. It is working. Okay, I'll switch my home network back to 6to4.

>They do no harm as their packets go nowhere.

The packets go fine. 

>The harm is done in support calls at various ISPs.

Stop being an ISP if you don't want customers.

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 18 Nov 2014 15:50:18 +0100

> Yes. It is working. Okay, I'll switch my home network back to 6to4.

Enjoy your broken connectivity...

>> They do no harm as their packets go nowhere.

Try that around the world to various destinations please.

> Stop being an ISP if you don't want customers. 

6to4 users are not the relay's customers, they are somebody elses
customers. Somebody else who has not bothered with this IPv6 thing...

Greets,
 Jeroen

---

From: "Dale W. Carder" <[email-masked]>
Date: Tue, 18 Nov 2014 09:04:13 -0600

> 3068 is causing operational problems

We tried 3068, found it did not work in practice as hoped, developed a 
number of alternatives, recommended hosts change their behavior, and 
only now are we documenting that we need to move on (years after many 
relay operators figured this out).

Dale

---

From: Tim Chown <[email-masked]>
Date: Tue, 18 Nov 2014 15:10:28 +0000

Hi,

> who reaps the befits, again).

I agree. Please proceed with marking as Historic.

Tim

---

From: Ray Hunter <[email-masked]>
Date: Tue, 18 Nov 2014 17:28:42 +0100

> if the return path works, or if the 2002::/16 prefix is properly announced.
We all know that.

The point is, does a blanket ISP filter on anycast routes for 6to4 
relays make the Internet better or worse?

My current view is that, on balance, recommending a filter is more 
harmful than helpful. But I'm willing to be convinced otherwise.
> There is a stack of problems that can be caused.
Sure. And these are well documented.
> announcement at all.
This I could certainly live with.

/An ISP SHOULD NOT advertise a route to 192.88.99.1unless they actively 
maintain an explicit route to a 6to4 anycast relay as per detailed in 
http://tools.ietf.org/html/rfc6343 Section 4.2.1/

> Better still, forbid anybody from announcing that
See above.
> As anycast 6to4 would be deprecated, that is kind of the point ;)
Nope. Deprecation does not equal breaking existing deployments.

-- 
Regards,
RayH

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 18 Nov 2014 17:38:39 +0100

>> if the return path works, or if the 2002::/16 prefix is properly

Depends on your definition of 'we all' I guess.

> relays make the Internet better or worse?

If with "filter" it means that the user gets a !N and thus an ICMP
Network Unreachable back, then yes, that will make things better.

The sooner their host gets the !N the quicker their host decides that it
is not working.

> harmful than helpful. But I'm willing to be convinced otherwise.

Depends on the filter. DROP would be bad, REJECT would be great.

I thus assume that with "filter" they mean "filter out the prefix from
BGP announcements".

Hence, the wording should also be like that and not that folks type the
equivalent of:

iptables -I FORWARD 192.88.99.1 -j DROP

as that will break things

> This I could certainly live with.

Filtering the BGP prefix would accomplish that. It would just mean that
you are 'protecting' your customers from the 6to4 anycast problem.

> http://tools.ietf.org/html/rfc6343 Section 4.2.1/

No. They MUST completely stop making 192.88.99.1/24 available.

Greets,
 Jeroen

---

From: Keith Moore <[email-masked]>
Date: Tue, 18 Nov 2014 11:51:51 -0500

> No. They MUST completely stop making 192.88.99.1/24 available.
That's completely ridiculous and inappropriate.

Keith

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 18 Nov 2014 17:56:08 +0100

> That's completely ridiculous and inappropriate.

Why? It ensures that their own users in their own network do not have
any problems with 6to4 anymore.

It does not affect any outside networks.

Over time 6to4 relay operators will shut them down and those routes will
go away anyway. Thus doing so with knowledge means that one can also
answer the phone and help the people fix their problem if they did rely
on 6to4.

Next to that, if the user wants to use a for them known-working 6to4
relay they can just point to that address instead of the well known
anycast address.

Hence, do a traceroute today to figure out to what you are talking...

Greets,
 Jeroen

---

From: Keith Moore <[email-masked]>
Date: Tue, 18 Nov 2014 11:59:22 -0500

> any problems with 6to4 anymore.
It's sabotage and you know it.  Either that or you have a strange belief 
that breaking anycast 6to4 equates to "no problems".

Keith

---

From: Michael H Lambert <[email-masked]>
Date: Tue, 18 Nov 2014 12:01:23 -0500

> No. They MUST completely stop making 192.88.99.1/24 available.

Maybe, maybe not.  But it strikes me as outside the scope of moving 6to4 to historic.

Michael

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 18 Nov 2014 17:05:30 +0000

> Maybe, maybe not.  But it strikes me as outside the scope of moving 6to4

if we're going to discuss deliberately setting out to break existing 6to4,
then this should be discussed in a new draft.  Deprecation or assignment to
historical status is merely a statement of status, not an operational
requirement to break things.

Can we please return to the stated intent of this draft, which is
deprecation / assignment of historical status?

Nick

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 18 Nov 2014 18:13:57 +0100

> deprecation / assignment of historical status?

This is being discussed because:

https://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-08

Section 4 "Deprecation"
8<------------------------
   Current operators of an anycast 6to4 relay with the IPv4 address
   192.88.99.1 SHOULD review the information in [RFC6343] and the
   present document, and then consider carefully when the anycast relay
   can be discontinued as traffic diminishes.  Internet service
   providers SHOULD filter out routes to 192.88.99.1.  However, networks

   SHOULD NOT filter out packets whose source address is 192.88.99.1,
   because this is normal 6to4 traffic from a 6to4 return relay
   somewhere in the Internet.
------------------------>8

The 2002::/16 is mentioned in the paragraph below it.

Greets,
 Jeroen

---

From: Philip Homburg <[email-masked]>
Date: Tue, 18 Nov 2014 18:48:44 +0100

>deprecation / assignment of historical status?

The current draft has a large amount of text unrelated to marking RFC 3068
as historic including this part:
"Internet service providers SHOULD filter out routes to 192.88.99.1"

which suggests actively breaking current use of 6to4.

---

From: Doug Barton <[email-masked]>
Date: Tue, 18 Nov 2014 11:23:18 -0800

On 11/18/14 6:02 AM, Keith Moore wrote:
>> It is really sad that the IETF asks for operator input but then
>> discards the input provided by those operators or keeps fighting their
>> input as non-truths.
>

Sure all of those things are contributors, but it sounds like you're in 
agreement that 6to4 is currently badly broken. So why are you fighting 
to keep it alive?

---

From: Sander Steffann <[email-masked]>
Date: Tue, 18 Nov 2014 22:56:35 +0300

Hi,

> Operator input is of course welcome and badly needed.   But that doesn't mean that everything said from an operator's point-of-view should be accepted without question.   The conditions that led to 6to4 not working well were a combination of: design oversights in both 6to4 and IP stacks, carrier behavior, local network operator behavior, and hardware vendor behavior in promoting NAT.   We don't do anyone a service by pretending that any of these weren't contributing to the problem.

They are of course part of the problem. The main problem is what Gert mentioned though. In theory the 6to4 anycast model could work, but the differences in who benefits versus who pays the cost make it unsustainable in practice.

Cheers,
Sander

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Nov 2014 08:57:32 +1300

Hi everybody,

I'm a bit disturbed by the amount of emotion and quasi-rudeness
in this thread. However, see below...

> requirement to break things.

This is proposed as a Best Current Practices document from an
Ops Area WG, so I think that operational requirements are
perfectly in scope. The question on the table is whether we do
or do not recommend filtering the anycast route.

Pro: it prevents people sending 6to4 packets to unreliable
anycast relays or to hosts that then send packets back to
unreliable return relays.

Con: it prevents people sending 6to4 packets to reliable anycast
relays and on to hosts that then send packets back to reliable
return relays.

Fact: apparently up to 100k people (who manage to contact Google
this way) are in the second category. We have no idea how many
people are in the first category.  People who use non-anycast
6to4 are not affected either way.

    Brian

---

From: Keith Moore <[email-masked]>
Date: Tue, 18 Nov 2014 15:24:57 -0500

> They are of course part of the problem. The main problem is what Gert mentioned though. In theory the 6to4 anycast model could work, but the differences in who benefits versus who pays the cost mak…
We keep being told that about the Internet itself, but somehow it has 
managed to work for these past thirty some-odd years...

I think the main problem is that Internet carriers regarded 6to4 relays, 
and (for many years) IPv6 in general, as "somebody else's problem" 
rather than essential services for their customers that needed 
provisioning and support.

Though, admittedly, to some degree we promoted 6to4 as a "hands off" 
solution, and that certainly didn't help.   And we could have done a 
much better job at designing both the relay routers and the anycast 
router discovery mechanism to make them more reasonable to support. *

Keith

* e.g. require the relay routers to support ICMP/ICMPv6; use anycast as 
part of a nearby router discovery mechanism that returns relay router 
IPv4 address(es) rather than as the address of the router itself.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 19 Nov 2014 07:39:33 +1100

> agreement that 6to4 is currently badly broken. So why are you fighting 

Because this draft isn't letting 6to4 die its natural death.  It's
attemping to prematurely kill 6to4.  6to4 will die when operators
finally deploy native IPv6 to everyone.  We already have lot of
guidance to people and vendor about when to and when not to deploy
6to4.

This draft does not help anyone with a currently broken 6to4
configuration.  We already have a RFC which is designed to help
them by turning off automatic configuration which by the way was
never recommended in any RFC.  By adjusting the addresses selection
rules.  By introducing faster failover.

The Google stats say that these measures are working, but these
stats are for dual stack services.  They also unload the remaining
relays for those that haven't upgraded their stacks.

What we don't have is stats for traffic to a popular IPv6 only sites.
Only then will we see who is still *relying* on 6to4 as modern nodes
won't use 6to4 except as a measure of last resort.

The fix for 6to4 is to deploy native IPv6.

IPv6 capable ISP's advertising that they support IPv6 would go a
long way to making native IPv6 everywhere a reality.

	"Comcast Cable with IPv6" or "Comcast Cable now with IPv6"
	"Time Warner Cable with IPv6" or "Time Warner Cable now with IPv6"

and eventually

	"Optus Cable with IPv6"

but I'm not holding my breath for that.

Two or three additional words added when generating new adverts.
If you are a early mover advertise the fact.

	"XXX bringing the new IPv6 Internet to you"

Mark

---

From: Gert Doering <[email-masked]>
Date: Tue, 18 Nov 2014 21:41:09 +0100

Hi,

> provisioning and support.

The main difference is: an ISP that doesn't provide a service his customers
want will eventually get customer complaints, and either start losing
customers or provide the service.

For 6to4, if an ISP runs a sloppy return relay, it will hit customers 
of *other* ISPs, who will have no way to complain to said ISP, as they
have no way to even notice who it is.

> router discovery mechanism to make them more reasonable to support. *

Yes, if people had done lots of things differently 20 or 30 years ago, 
we wouldn't have these discussions today.  But you didn't.

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Tue, 18 Nov 2014 21:44:46 +0100

Hi,

> 	"XXX bringing the new IPv6 Internet to you"

That ship sailed 15 years ago, and didn't have travellers on it.

Customers do not care what mystic method you use to deliver their facebook
or youtube content, and IPv6 is *not* a selling argument ("we have public
IPv4!" might be, unfortunately).  

We tried for about 10 years, and it just does not work.  Well, you make 
yourself a name in the geek community, and you can do press releases (which 
are useful, undoubtedly, because your name is in print, no matter what
the reason), but it does not attract new customers in any significant way.

Gert Doering
        -- NetMaster

---

From: Keith Moore <[email-masked]>
Date: Tue, 18 Nov 2014 15:45:19 -0500

> have no way to even notice who it is.

How is the return relay any different than any other case of IPv6 
routing?   Is it just that nobody bothered to make formal 
service/peering agreements to provide and support connectivity to 
2002::/16 ?

> we wouldn't have these discussions today.  But you didn't.
And neither did the ISPs.   But yes, this is of course water that has 
long since passed under the bridge.

Keith

p.s. I should probably try to capture this stuff, maybe for an 
informational RFC, or maybe just for a blog post.   But I don't think 
it's been done justice in existing RFCs.

---

From: Keith Moore <[email-masked]>
Date: Tue, 18 Nov 2014 15:48:39 -0500

+1

---

From: Ray Hunter <[email-masked]>
Date: Tue, 18 Nov 2014 21:59:03 +0100

Brian E Carpenter wrote:
>>> On 18 Nov 2014, at 11:38, Jeroen Massar<[email-masked]>  wrote:
>>>
Hence my proposal to amend this anycast filter text to

Which IMHO should facilitate the Pro without triggering the Con.

Apologies for repetition, but this was cut from all the replies in the 
thread (either accidentally or deliberately).

-- 
Regards,
RayH

---

From: Sander Steffann <[email-masked]>
Date: Wed, 19 Nov 2014 00:04:34 +0300

Hi,

> Op 18 nov. 2014 om 23:24 heeft Keith Moore <[email-masked]> het volgende geschreven:
> 
> We keep being told that about the Internet itself, but somehow it has managed to work for these past thirty some-odd years...

The internet works because everybody who participates sees a value in it. Fire example transit providers make money by transporting other network's packets. They don't do it for free. Running a public 6to4 relay costs money but doesn't provide much value for the operator running it. There is no way to even recover the cost. It doesn't even have PR value because nobody can see which relay they are using.

Every ISP running their own relays and managing them properly would have helped but that doesn't scale. And it would defeat the purpose of providing IPv6 to users whose ISP doesn't/can't provide native IPv6...

Cheers,
Sander

---

From: Keith Moore <[email-masked]>
Date: Tue, 18 Nov 2014 16:13:36 -0500

On 11/18/2014 04:04 PM, Sander Steffann wrote:
> The internet works because everybody who participates sees a value in it.

More precisely, (almost) everybody sees value in providing connectivity 
to the whole Internet, rather than just certain address blocks.   They 
sell "Internet connectivity" rather than "Google connectivity" or 
"Amazon connectivity" or "Netflix connectivity".

So one way to describe the problem with providing 6to4 relays (or 
connectivity to such relays) is that some providers didn't see the hosts 
on the other side of those relays as part of the "whole Internet" - and 
thus, not worth bothering with.   Of course, there wasn't much customer 
demand for that specific kind of connectivity, but neither is there much 
customer demand for connectivity to most prefixes.   Most customers 
don't want to pick and choose which Internet channels they get.

>   Fire example transit providers make money by transporting other network's packets. They don't do it for free. Running a public 6to4 relay costs money but doesn't provide much value for the operator running it. There is no way to even recover the cost. It doesn't even have PR value because nobody can see which relay they are using.
>
> Every ISP running their own relays and managing them properly would have helped but that doesn't scale.

I think it would have scaled just fine until native v6 were ready. 
(People were originally worried about 6to4 being so attractive that 
there would be a temptation to advertise prefixes longer than /16 within 
2002:: space.   In hindsight that would have been fantastic success and 
a great problem to have.)

Keith

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 18 Nov 2014 21:21:27 +0000

Brian,

On 18/11/2014 19:57, Brian E Carpenter wrote:
> This is proposed as a Best Current Practices document from an Ops Area 
> WG, so I think that operational requirements are perfectly in scope.
> The question on the table is whether we do or do not recommend filtering
> the anycast route.

Stepping back back a bit, I briefly skimmed down through rfc-index, and the
only thing that pretty much all the -to-historic RFCs (with the exception
of rfc6563 - A6 deprecation) do is to change the status of the rfc from
Standards Track/BCP to Historic.

The IESG's statement on historic status is here:

> https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html

The following text is germane to the discussion in v6ops at the moment:

> A document is labelled Historic when what it describes is no longer 
> considered current: no longer recommended for use.

So the question for this draft is whether it actually needs to go beyond a
single paragraph changing the status of RFC3068 to historic.

Historic status will automatically signal to vendors that the protocol
should be deprecated on their implementations and to operators that they
should let the protocol die away on its own.  This will leave the internet
in a status where end-users can potentially enable it by explicitly going
out of their way to do so, but it will not be available on default
installation.  From what I can tell, this is the LCD for pretty much
everyone who's contributed to this discussion.

Nick

---

From: Mark Andrews <[email-masked]>
Date: Wed, 19 Nov 2014 08:24:34 +1100

> 6to4 are not affected either way.

Talk about biased descriptions.

Fact: 100k nodes in the second category talk to Google.
Fact: we have no way to measure the number in the first category.
Fact: we have no way to measure the number in the second category.

Fact: turning filtering 192.88.99.1 will have no impact on people
in the first category.  They go from non working to still non working.

Fact: turning filtering 192.88.99.1 will will have a impact on people
in the second category. They go from work to non working.

If there is a non working relay it should be turned off.  Filter routes
does not help.  Period.

---

From: [email-masked]
Date: Tue, 18 Nov 2014 22:48:48 +0100 (CET)

> Which IMHO should facilitate the Pro without triggering the Con.

Disagree.

We receive 192.88.99.1 (really 192.88.99.0/24) from several different
peers and from one of our transit providers. However,

- Not all 192.88.99.1 relay addresses are pingable. Regarding RFC 6343
Section 4.2.1 - we *do not know* the answers to items 2 and 3.

- Since the prefix is announced to us, we *assume* that the relays will
accept traffic, but again we *do not know* the answer to item 4.

We turned off our own 6to4 relay nearly two years ago, and we have no
plans to turn it on again. Despite this, we will *not* start blocking
192.88.99.1. Our answer to the problem of unreliable 6to4 is native
IPv6, *not* stopping existing users of 6to4.

Steinar Haug, AS 2116

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Nov 2014 11:07:22 +1300

> Fact: 100k nodes in the second category talk to Google.

Actually, we can't be certain they are coming via an anycast
relay - technically they could be coming via a unicast relay -
but it's a fairly safe assumption.

> Fact: we have no way to measure the number in the second category.

Well, true, we don't know how many people successfully use
anycast 6to4 but never use Google. I'm prepared to assume that
it's a fairly small number, and that 100k is the correct order
of magnitude. If the real number is 200k it doesn't really
change the argument very much.

> If there is a non working relay it should be turned off.  Filter routes

I suspect that filtering the route will simplify the help desk's
response, but I see your (and Steinar Haug's) logic.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Nov 2014 11:19:37 +1300

> Standards Track/BCP to Historic.

Yes, and that is very unenlightening to outsiders.

> single paragraph changing the status of RFC3068 to historic.

That decision has operational implications, and IMHO we would be
derelict in our duty if we did not document them. The IESG
statement concerns relatively simple cases; I doubt anybody
would describe anycast 6to4 as operationally simple. To me,
a BCP that formally obsoletes RFC 3068 and makes clear
recommendations is the most appropriate vehicle.

> should let the protocol die away on its own.  

IMHO, "die away on its own" works well for an end-to-end
protocol, but anycast 6to4 is an
end-to-middlebox-to-end-to-middlebox-to-end protocol and those
things don't die quietly and unobtrusively.

> This will leave the internet

Agreed, but that doesn't mean we should duck the operational
aspects (otherwise this discussion would be in 6man).

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Nov 2014 11:32:05 +1300

Hi Keith,

> On 11/18/2014 03:41 PM, Gert Doering wrote:

...
> service/peering agreements to provide and support connectivity to

I think that's right, and it's the same for classical (RFC3056)
6to4 and anycast 6to4. This is discussed in reasonable detail in
RFC 6343, and I don't there is anything much new to say (except
for the point about colocating such a relay with NAT64 that was
brought up recently).

   Brian

---

From: Sander Steffann <[email-masked]>
Date: Wed, 19 Nov 2014 08:37:14 +0300

Hi Keith,

> More precisely, (almost) everybody sees value in providing connectivity to the whole Internet, rather than just certain address blocks.   They sell "Internet connectivity" rather than "Google connectivity" or "Amazon connectivity" or "Netflix connectivity".

Yes, they sell internet connectivity.

> So one way to describe the problem with providing 6to4 relays (or connectivity to such relays) is that some providers didn't see the hosts on the other side of those relays as part of the "whole Internet" - and thus, not worth bothering with.

'the hosts on the other side of those relays' depends on your point of view.

1) If you're talking about an ISP offering a relay to its own IPv4 customers then the hosts on 'this' side of the relay would be its own customers and they would care about connectivity to the hosts on the other side. But an ISP that can provide a 6to4 relay would rather provide native IPv6 (or managed tunnels or 6rd etc) to avoid problems with return relays. Officially providing a 6to4 service causes too many difficult debugging problems, too many calls to the helpdesk etc. So ISPs usually offer an IPv6 solution they can control or nothing at all, but not 6to4.

2) If you're talking about public 6to4 relays then they have no relationship with both sides of the relay. Both the 6to4 side and the native IPv6 side would be 3rd parties to which they are providing a free transit-like service. There have been public relays like this but their stability and performance has been bad in too many cases. None of the users are paying for these public relays and everyone who is near (in BGP terms) to a bad relay has IPv6 connectivity problems.

3) The most value is gained by providing only the IPv6->6to4 (announce 2002::/16 but not 192.88.99/24) to ones own customers. Then at least the return path to 6to4 users would be predictable. But given all the other problems encountered (bad filtering, unstable 6to4->IPv6 relays etc) and the difficulty (impossibility?) of debugging a system where anyone can announce the anycast addresses no matter how bad their service has caused most ISPs not to want to go there. I have run such relays for networks that I was responsible for in the past but at some point the benefit versus the cost of maintaining them shifted to much that it was better (for the ISP) to turn them off. So we did try but it was never really worth it. Big content providers like Google never even bothered with deploying such relays.

So, yes, it was 'not worth bothering with' for most ISPs, which is exactly the point. Not because they were not seen as 'part of the whole Internet' but because the economics and benefits never worked for the 6to4 anycast relay model.

Cheers,
Sander

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Nov 2014 01:25:27 -0500

> 1) If you're talking about an ISP offering a relay to its own IPv4 customers then the hosts on 'this' side of the relay would be its own customers and they would care about connectivity to the host…

Fair point.  If I were running an ISP I'd probably implement 6rd as my 
preferred near-term solution to provide my customers with v6 access.  
Though I might also support an outgoing 6to4 relay (though perhaps not 
at the anycast address, or perhaps at the anycast address but filtering 
the outgoing prefix advertisement) as 6to4 seems to be more widely 
supported in hosts and routers.

> 3) The most value is gained by providing only the IPv6->6to4 (announce 2002::/16 but not 192.88.99/24) to ones own customers. Then at least the return path to 6to4 users would be predictable. But given all the other problems encountered (bad filtering, unstable 6to4->IPv6 relays etc) and the difficulty (impossibility?) of debugging a system where anyone can announce the anycast addresses no matter how bad their service has caused most ISPs not to want to go there. I have run such relays for networks that I was responsible for in the past but at some point the benefit versus the cost of maintaining them shifted to much that it was better (for the ISP) to turn them off.
How was it better?   Did the ISP's 6to4 customers' service improve for 
lack of a local IPv6->6to4 relay?   Unless that relay were closer to the 
native IPv6 peer, I don't see how it would help one's own 6to4 customers 
much.   Seems like the best way to help one's own customers run 6to4 
would be to provide a 6to4->v6 relay.  But if the native v6 peer's 
nearest router to 2002::/16 doesn't work well, the customer's probably 
out of luck and there's not much his ISP can do about it.   The same is 
true if you're using 6rd on your side and the native v6 peer's nearest 
router advertising reachability to your v6 prefix doesn't work well, but 
maybe then you have service agreements in place and can get the problem 
fixed.

> So we did try but it was never really worth it. Big content providers like Google never even bothered with deploying such relays.

Right, but they didn't have a pressing need to use v6 anyway.   They had 
enough public v4 addresses for everything they needed to do, all of 
their customers already had v4 access, and they were running an 
application that happens to work well over NAT.  Some of them just 
happened to be forward-thinking enough to be experimenting with v6 well 
before it would be needed to work at scale.

> So, yes, it was 'not worth bothering with' for most ISPs, which is exactly the point. Not because they were not seen as 'part of the whole Internet' but because the economics and benefits never wor…

To me it looks like the crux of the problem is this:  6to4 forbade the 
v6->6to4 router advertising a prefix longer than 2002::/16, because 
nobody wanted the class C swamp imported into v6 space. But for that 
reason there was no way to influence which routers or networks would be 
providing the return path to one's own customers, and thus no way to 
provision that service.   From the point of view of the 6to4 user and 
his ISP, the return path was entirely random.

And though there are problems with using anycast on the v4 side, 
particularly across network boundaries, I don't see how the use of 
anycast caused this particular problem.   An ISP can provide its 6to4 
customers with a good outbound path to v6 land; it just has no influence 
at all on the return path.

Keith

---

From: Sander Steffann <[email-masked]>
Date: Wed, 19 Nov 2014 09:56:30 +0300

Hi,

Quote which I will refer to later (*)
> [...]
>> So ISPs usually offer an IPv6 solution they can control or nothing at all, but not 6to4.
> 
> Fair point.  If I were running an ISP I'd probably implement 6rd as my preferred near-term solution to provide my customers with v6 access.
> [...]

> How was it better?

Cost vs benefit

>   Did the ISP's 6to4 customers' service improve for lack of a local IPv6->6to4 relay?   Unless that relay were closer to the native IPv6 peer, I don't see how it would help one's own 6to4 customers much.

There were not enough users and the presence of a local relay didn't improve the end user experience enough to justify the cost of the relay.

>   Seems like the best way to help one's own customers run 6to4 would be to provide a 6to4->v6 relay.

But providers that can do this would rather deploy native IPv6, managed tunnels or 6rd. That was point 1. Point 3 is the other way around.

>  But if the native v6 peer's nearest router to 2002::/16 doesn't work well, the customer's probably out of luck and there's not much his ISP can do about it.

Providing 2002::/16 to native local IPv6 servers/users/etc is what I was talking about (point 3). In the end running a local ipv6->6to4 relay didn't have enough benefits for the ipv6 side, and the 6to4 side has no control over that direction. So in practice the return path almost completely relies on public relays (point 2). And as I described there is no real incentive for ISPs to run well-managed public relays.

>   The same is true if you're using 6rd on your side and the native v6 peer's nearest router advertising reachability to your v6 prefix doesn't work well, but maybe then you have service agreements in place and can get the problem fixed.

ISPs run those relays (both inbound and outbound) themselves and manage them as part of their service. There is incentive to do this well (mostly reduced helpdesk cost).

> Right, but they didn't have a pressing need to use v6 anyway.   They had enough public v4 addresses for everything they needed to do, all of their customers already had v4 access, and they were running an application that happens to work well over NAT.  Some of them just happened to be forward-thinking enough to be experimenting with v6 well before it would be needed to work at scale.

They deployed production quality native IPv6, but choose not to deploy local 6to4 relays. IIRC they did consider it but the cost/benefit ratio didn't work out for them.

> To me it looks like the crux of the problem is this:  6to4 forbade the v6->6to4 router advertising a prefix longer than 2002::/16, because nobody wanted the class C swamp imported into v6 space. But for that reason there was no way to influence which routers or networks would be providing the return path to one's own customers, and thus no way to provision that service.   From the point of view of the 6to4 user and his ISP, the return path was entirely random.

Yes, this was indeed a problem. If that had been allowed then an ISP could have provided 192.88.99.1 to its local users and announce the return path route 2002:xxxx:xxxx::/yy for its users in BGP and we wouldn't have needed 6rd. The ISP could get control and management over both sides of the relay and they could provide a reliable service to their own users.

> And though there are problems with using anycast on the v4 side, particularly across network boundaries, I don't see how the use of anycast caused this particular problem.   An ISP can provide its 6to4 customers with a good outbound path to v6 land; it just has no influence at all on the return path.

But like I said (and you confirmed (*)) in point 1: such ISPs would rather deploy managed IPv6 like 6rd (which is basically a kind of 6to4 which can be locally managed). 6to4 for customers of other ISP would still have to rely on public anycast relays, which have proven to be a nightmare to debug.

I hope you now understand better why the 6to4 anycast relays idea hasn't worked. I sometimes see other ideas that use a similar kind of anycast relay structure and I hope that this discussion has provided a clearer picture for everyone here so that this can be taken into account in future IETF work. Protocols that rely on unknown 3rd parties providing public relays (or every ISP/network having to deploy local relays to avoid such 3rd party relays) without any real benefit to themselves just won't fly.

Cheers,
Sander

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Nov 2014 02:15:55 -0500

On 11/19/2014 01:56 AM, Sander Steffann wrote:
> 3) The most value is gained by providing only the IPv6->6to4 (announce 
> 2002::/16 but not 192.88.99/24) to ones own customers. Then at least 
> the return path to 6to4 users would be predictable. But given all the 
> other problems encountered (bad filtering, unstable 6to4->IPv6 relays 
> etc) and the difficulty (impossibility?) of debugging a system where 
> anyone can announce the anycast addresses no matter how bad their 
> service has caused most ISPs not to want to go there. I have run such 
> relays for networks that I was responsible for in the past but at some 
> point the benefit versus the cost of maintaining them shifted to much 
> that it was better (for the ISP) to turn them off.
>> How was it better?
> Cost vs benefit

Ok, so turning such relays off worsened service for their customers, but 
saved enough money that the ISP judged it was worth it anyway.

But I certainly get that if you're running an ISP today, and you're not 
yet in a position to provide native v6 to your customers, you'd far 
rather provide 6rd and encourage them to do whatever they had to do to 
use that, than try to make 6to4 work for them.   The only reason you 
wouldn't do that might be if your upstream providers didn't speak v6 
either (which I hope isn't a problem anymore, but might have been when 
6to4 was first published.).

> Providing 2002::/16 to native local IPv6 servers/users/etc is what I was talking about (point 3). In the end running a local ipv6->6to4 relay didn't have enough benefits for the ipv6 side, and the 6to4 side has no control over that direction.

Right, and there might be a perceived asymmetry of benefit there. The 
native v6 network customers don't see themselves as needing good access 
to 6to4, so they don't insist on having good relays on their side.   But 
the v4-only customers trying to use 6to4 do see themselves as needing 
good access to native v6.

> They deployed production quality native IPv6, but choose not to deploy local 6to4 relays. IIRC they did consider it but the cost/benefit ratio didn't work out for them.

My point was that the potential benefit to them, even if 6to4 had worked 
perfectly, was low-to-nonexistent anyway.

> I hope you now understand better why the 6to4 anycast relays idea 
> hasn't worked. 

I think I do.   What I don't see is how the problem you're describing 
has anything to do with anycast.

Keith

---

From: Ray Hunter <[email-masked]>
Date: Wed, 19 Nov 2014 09:55:55 +0100

> [email-masked] <mailto:[email-masked]>
> 18 November 2014 22:48
>
> Disagree.
>
The new BCP text that I proposed is a SHOULD NOT _advertise_.

If your AS chooses to _learn_ the route to 192.88.99.1 from others for 
your own operational reasons, that's entirely up to you, and I've 
proposed no BCP for that.

But if you really want to 6to4 to work, I hope that you would want that 
the AS'es who advertise 192.88.99.1 to you to follow existing advice 
from RFC6343 to make sure any anycast route to 192.88.99.1 that you 
learn for your users is a useful one.

Because the people who operate good 6to4 relays SHOULD be able to answer 
those questions.

If you choose to ignore a "SHOULD NOT" BCP for your own good reasons, 
and advertise 192.88.99.1 to other AS peers, that's also up to you, but 
you should be aware that you might be passing on "bad" anycast relays to 
others, and harming them.

regards,
> Ray Hunter <mailto:[email-masked]>
> 18 November 2014 21:59
>
>
>
> /An ISP SHOULD NOT advertise a route to 192.88.99.1unless they 
> actively maintain an explicit route to a 6to4 anycast relay as per 
> detailed in http://tools.ietf.org/html/rfc6343 Section 4.2.1/
>
> ------------------------------------------------------------------------

-- 
Regards,
RayH

---

From: Tore Anderson <[email-masked]>
Date: Wed, 19 Nov 2014 10:07:02 +0100

* Ray Hunter

> If your AS chooses to _learn_ the route to 192.88.99.1 from others
> for your own operational reasons, that's entirely up to you, and I've 

A transit AS who learns the 6to4 prefixes from an upstream or peer
will advertise it to its customers. I initially intepreted your
suggested text to understand that a transit AS should explicitly
suppress such advertisements to my customers, but from the above I
understand that is probably not the intention? If so, perhaps replace
"advertise" with "originate"?

Tore

---

From: Sander Steffann <[email-masked]>
Date: Wed, 19 Nov 2014 12:44:05 +0300

Hi Keith,

> I think I do.   What I don't see is how the problem you're describing has anything to do with anycast.

It makes contacting the operator of a broken relay almost impossible because you don't see which relay it is.

Cheers,
Sander

---

From: [email-masked]
Date: Wed, 19 Nov 2014 10:52:08 +0100 (CET)

> learn for your users is a useful one.

We don't really care about 6to4, and don't plan to use time on making
it work/be useful. *If* our customers find it useful - no problem, we
won't actively suppress the 6to4 prefixes.

> others, and harming them.

We certainly won't advertise to peers. We *will* carry those prefixes
within our AS, and we *will* route traffic to those prefixes. Also,
we *will* advertise it to those customers who have requested a full
routing table. If those customers find it useful - fine, no problem.
If they don't find it useful - also fine, no problem.

In other words - there will be *no* special treatment for the 6to4
prefixes - they will be treated just like any other prefixes we receive
on transit/peering links.

Steinar Haug, AS 2116

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 19 Nov 2014 10:57:54 +0100

How Steinar describes it below is how it should be put into the RFC.

The big problem with recommending filtering a prefix is that those
filters never get removed. Though we might not care for a single /24 IPv4...

Greets,
 Jeroen

[..]

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 19 Nov 2014 11:47:43 +0000

On 18/11/2014 22:19, Brian E Carpenter wrote:
> derelict in our duty if we did not document them.

yes, but there's a wide gulf between documenting operational implications
and making specific recommendations to block traffic of a particular form.
I have no problem with the former.

Nick

---

From: Ray Hunter <[email-masked]>
Date: Wed, 19 Nov 2014 13:55:47 +0100

> "advertise" with "originate"?
After reading the various reactions, your amendment would seem to result 
in a reasonable piece of BCP that everyone could live with, allowing 
graceful sunsetting, whilst avoiding "bad" relays.

So I propose:

s/Internet service providers SHOULD filter out routes to 
192.88.99.1./Internet service providers and other network providers 
SHOULD NOT originate a route to 192.88.99.1, unless they actively 
maintain a path to an outbound 6to4 relay service as detailed in 
http://tools.ietf.org/html/rfc6343 Section 4.2.1/

-- 
Regards,
RayH

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 19 Nov 2014 21:57:43 +0900

On Wed, Nov 19, 2014 at 9:55 PM, Ray Hunter <[email-masked]> wrote:

> 192.88.99.1./Internet service providers and other network providers SHOULD
> NOT originate a route to 192.88.99.1, unless they actively maintain a path
> to an outbound 6to4 relay service as detailed in

LGTM, except maybe change "maintain" to "maintain and monitor".

---

From: Tore Anderson <[email-masked]>
Date: Wed, 19 Nov 2014 14:08:20 +0100

* Lorenzo Colitti <[email-masked]>

> LGTM, except maybe change "maintain" to "maintain and monitor".

Mhm. I'm not exactly sure how to interpret the "a path to"
statement though. Saying «... unless they actively maintain [and
monitor] an outbound 6to4 relay service ...» sounds better to me, unless
there's some specific meaning to the "a path to" statement that I'm not
getting.

I'd also upgrade the SHOULD NOT to MUST NOT. I can think of no valid
reasons to originate 6to4 route announcements if you're not prepared to
relay the traffic. Doing so isn't much different from a route
hijack/leak.

Tore

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 19 Nov 2014 14:09:05 +0100

On 2014-11-19 13:57, Lorenzo Colitti wrote:
> On Wed, Nov 19, 2014 at 9:55 PM, Ray Hunter <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     http://tools.ietf.org/html/__rfc6343
>     <http://tools.ietf.org/html/rfc6343> Section 4.2.1/
> 
> 

Agreed, that would make it as good as one could possibly make it while
keeping it succint.

Greets,
 Jeroen

---

From: Philip Homburg <[email-masked]>
Date: Wed, 19 Nov 2014 14:16:02 +0100

>http://tools.ietf.org/html/rfc6343 Section 4.2.1/

Is this really a problem that needs solving?

On any modern operating system, the only way to trigger use of 6to4 is either
trying to connect to DNS name that has only a AAAA or to an IPv6 address literal.

I think we can safely assume that people who have a need to connect to IPv6-only
systems can also verify that 6to4 is actually working and complain to whoever
advertises a relay that doesn't work.

I.e. can't we just leave it to RFC 6343 to say what needs to be said about
6to4 and leave it alone?

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Nov 2014 12:56:49 -0500

> advertises a relay that doesn't work.
no, we can't safely assume that, because there's no good way for the 
average user to know who is actually operating that relay.

Keith

---

From: "Dale W. Carder" <[email-masked]>
Date: Wed, 19 Nov 2014 12:01:38 -0600

Thus spake Keith Moore ([email-masked]) on Wed, Nov 19, 2014 at 12:56:49PM -0500:
> no, we can't safely assume that, because there's no good way for the average
> user to know who is actually operating that relay.

And that's a great reason why we need to deprecate the anycast service.

Dale

---

From: Philip Homburg <[email-masked]>
Date: Wed, 19 Nov 2014 19:22:12 +0100

>average user to know who is actually operating that relay.

The average user doesn't connect to IPv6-only sites. So that's not an issue.

For more tech savvy users, a traceroute to 192.88.99.1 isn't that hard.

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Nov 2014 13:24:41 -0500

On 11/19/2014 01:22 PM, Philip Homburg wrote:
> The average user doesn't connect to IPv6-only sites.
The average user has no idea whether he's connecting to an IPv6-only 
site or not.   Which is as it should be.

(and please stop assuming that the Internet is all about connecting to 
"sites")

> So that's not an issue.
No, but neither does it really tell you how to get the problem fixed.

Keith

---

From: Philip Homburg <[email-masked]>
Date: Wed, 19 Nov 2014 19:31:14 +0100

>site or not.   Which is as it should be.

Average users are not (currently) connecting to IPv6-only 'sites'. That's
just silly. The average user only has IPv4.

The average user doesn't even know what 6to4 is, let alone how to enable it.
The time that devices would enable 6to4 automatically should be behind us.

>No, but neither does it really tell you how to get the problem fixed.

Of course it does. You can either get in contact with the people running the
relay or you disable 6to4. Very simple.

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Nov 2014 13:37:00 -0500

> just silly. The average user only has IPv4.

This is changing.   And the problem isn't just 6to4 users trying to get 
to native v6 destinations; the other problem also exists.

> The time that devices would enable 6to4 automatically should be behind us.

Yes, but I'm sure that there are still some users out there using it 
"accidentally" for one reason or another.

On the other hand, the various recommendations to discourage accidental 
use of 6to4 (address selection, off by default, happy eyeballs) have 
been published for awhile, and nothing that we publish now is likely to 
accelerate that trend.   There's an inherent time lag there.

> relay or you disable 6to4. Very simple.
As one of the people who have used 6to4 the longest, my success rate 
over the years at getting in contact with people running such relays has 
been zero.  And disabling 6to4 doesn't fix the problem, it just moves it.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Nov 2014 08:15:52 +1300

Philip,

On 20/11/2014 02:16, Philip Homburg wrote:
> On any modern operating system, 

I suspect that many of the people who still see lousy timeouts
caused by 6to4 black holes are *not* running that modern an o/s.
They are still in RFC 3484 and Unhappy Eyeballs territory. And
they are not typically readers of any RFC, including RFC 6343.

   Brian

> the only way to trigger use of 6to4 is either
> .

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Nov 2014 08:20:07 +1300

> been zero.  And disabling 6to4 doesn't fix the problem, it just moves it.

And Keith, as co-designer of classical 6to4, is on the
relatively short list of people who should be able to debug 6to4
problems if anybody can. I can exactly match his experience:
contacting operators of faulty relays (or of hosts that screw up
MSS negotiation through 6to4 tunnels) is impossible in practice.

Only a tiny minority of 6to4 users could even begin to
understand this conversation.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Nov 2014 08:23:13 +1300

> relay the traffic. Doing so isn't much different from a route

OK, there is some editorial work to do here, but it seems to me
that we're very close to most of us agreeing on a way forward. I
don't want to confuse matters by posting a new version during
the WGLC period, however.

    Brian

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Nov 2014 15:30:43 -0500

I've been trying to figure out what I think about the practice of filtering anycast router advertisements.  Originally I thought it was ok for ISPs to do that if they wished; now I'm not so sure.  I can understand why an ISP would want to filter advertisements to specific relays known to cause problems, just like any other black hole route.  But I don't think they're doing anyone any favors by filtering such routes - last I knew, the hosts would still send such traffic and generally ignore any ICMP responses to such traffic.

One thing I'm fairly confident about: an ISP has no business deliberately breaking anycast 6to4 router service for customers to whom it doesn't offer an alternative form of v6 access.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 20 Nov 2014 14:15:30 +0100

>they are not typically readers of any RFC, including RFC 6343.

The changes in operating systems are intended to prevent those timeouts. So
it is rather likely that people who experiencing timeouts are running old
stuff.

But there is nothing we can do about that. There is no mechanism to signal
to old CPEs that they have to stop annoucing a 6to4 prefix on the local lan.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 20 Nov 2014 15:02:47 +0100

>to native v6 destinations; the other problem also exists.

In what sense it that changing? 

The only IPv6-only destinations I ever see mentioned are sites that report
your IPv6 address.

Of course a lot more than that exists. But I have never seen it mentioned by
an ordinary user.

>accelerate that trend.   There's an inherent time lag there.

Yes, there will be some users using old operating systems. There is nothing we
can do to help them. 

>been zero.  And disabling 6to4 doesn't fix the problem, it just moves it.

Disabling 6to4 solves the problem of getting timeouts due to a badly operating
relay. Of course it leaves you without IPv6 access but that what you get
from using a free service.

For people who are interested in this kind of stuff, here are the
results of a traceroute on RIPE Atlas from all probes to 192.88.99.1
https://atlas.ripe.net/measurements/1790543/#!probes

for comparison, here is the results only for the probes that seem to have picked
up a 6to4 address:
https://atlas.ripe.net/measurements/1790525/#!probes

Interestingly, just about all relays (found by Atlas probes) seem to respond
to ICMP pings.

---

From: "Metzler, Dan J" <[email-masked]>
Date: Thu, 20 Nov 2014 14:32:02 +0000

Hi Brian,

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Tuesday, November 18, 2014 4:07 PM
> To: Mark Andrews
> Cc: [email-masked]
> Subject: Re: [v6ops] Filtering anycast 6to4 [draft-ietf-v6ops-6to4-to-historic
> WGLC]
> 
> >> I'm a bit disturbed by the amount of emotion and quasi-rudeness in
> >> this thread. However, see below...
> >>
> >>> if we're going to discuss deliberately setting out to break existing
> >>> 6to4, then this should be discussed in a new draft.  Deprecation or
> >>> assignment to historical status is merely a statement of status, not
> >>> an operational requirement to break things.
> >> This is proposed as a Best Current Practices document from an Ops
> >> Area WG, so I think that operational requirements are perfectly in
> >> scope. The question on the table is whether we do or do not recommend
> >> filtering the anycast route.
> >>
> >> Pro: it prevents people sending 6to4 packets to unreliable anycast
> >> relays or to hosts that then send packets back to unreliable return
> >> relays.
> >>
> >> relays and on to hosts that then send packets back to reliable return
> >> relays.
> >>
> >> Fact: apparently up to 100k people (who manage to contact Google this
> >> way) are in the second category. We have no idea how many people are
> >> in the first category.  People who use non-anycast
> Actually, we can't be certain they are coming via an anycast relay - technically
> they could be coming via a unicast relay - but it's a fairly safe assumption.

I'm not sure how safe that assumption really is, not knowing anything about Google's network and endpoints, or those of the addresses that are being reported.

> Well, true, we don't know how many people successfully use anycast 6to4 but
> never use Google. I'm prepared to assume that it's a fairly small number, and
> that 100k is the correct order of magnitude. If the real number is 200k it
> doesn't really change the argument very much.

Given the nature of address selection, I don't see how that number means anything other than possibly the number of endpoints that will no longer be able to reach Google if 6to4 goes away in its entirety.
To my knowledge Google is not really IPv6 only.  Nearly all of the population that relies on 6to4 anycast for access to IPv6 only content is likely to use IPv4 instead of IPv6 when attempting to reach Google just because of the nature of address selection, right?  So is this number relevant to this discussion?

Thanks,

- Dan

---

From: "Metzler, Dan J" <[email-masked]>
Date: Thu, 20 Nov 2014 15:38:49 +0000

Hi Philip,

> From: v6ops [mailto:[email-masked]] On Behalf Of Philip Homburg
> Sent: Thursday, November 20, 2014 8:03 AM
> To: Keith Moore
> Cc: [email-masked]
> >> Average users are not (currently) connecting to IPv6-only 'sites'.
> >> That's just silly. The average user only has IPv4.
> >
> The only IPv6-only destinations I ever see mentioned are sites that report your
> IPv6 address.
> 
> Of course a lot more than that exists. But I have never seen it mentioned by an
> ordinary user.
> 
> >> Of course it does. You can either get in contact with the people
> >> running the relay or you disable 6to4. Very simple.
> >over the years at getting in contact with people running such relays
> >has been zero.  And disabling 6to4 doesn't fix the problem, it just moves it.
> 
> relay. Of course it leaves you without IPv6 access but that what you get from
> using a free service.

Disabling 6to4 would solve the problem of getting timeouts due to a badly operating relay provided it is done correctly, but so would fixing the badly operating relay.
I realize that isn't necessarily a trivial task because it means tracking down the owner, and convincing them to do something about it.  
This is all the more difficult because often the relay is fine, and in my opinion, the problem, (which many seem to want to overlook), is more to do with somebody else in between the source and the destination who has determined that 6to4, (or more likely IPv6), is bad and should be stopped.  (Often at the advice of a firewall vendor  who's product doesn't adequately support IPv6.)

Never-the-less, I think a BCP document, should be advocating, the fixing of problems, not work to break 6to4 further than it already is in the name of "deprecation".  If we don't want to seek out the broken relays, and have them turned off or fixed, shouldn't it be up to the endpoint to disable their IPv6 access rather than a network operator somewhere in between.  There is nothing preventing people from shutting off 6to4 on the endpoints if desired.  (That will also solve the problem of timeouts for them, but won't affect those who successfully use 6to4.)  Likewise there is nothing preventing people from fixing a misbehaving relay.

A "free" service may have economic challenges, but that doesn't mean IETF should actively seek out "free" services and advocate breaking them, nor should we arbitrarily turn up our noses at them.  For most of us, the internet can't work without "free" services.  DNS roots being just one case in point.  ("Free" services are an illusion, as nothing is really free.  That's really just a term invented, in my opinion, so  we can have political arguments.  The reality is somebody pays for it, and they do so because they ultimately they want to.)  I don't think it should be the job of IETF to dictate which cost recovery models are acceptable and which aren't.

I'm all for deprecation, but I just don't think it's the right time to arbitrarily shut it down, given that there is no replacement for the main use case of 6to4 anycast.  (As far as I know.)

Thanks,

- Dan

---

From: Keith Moore <[email-masked]>
Date: Thu, 20 Nov 2014 10:41:27 -0500

> In what sense it that changing?
More and more users have IPv6 in addition to IPv4.

> Of course a lot more than that exists. But I have never seen it mentioned by

Far too many arguments in this space are based on the idea of an 
"ordinary user" who does nothing but visit "sites".   In reality, there 
is a huge spectrum of users and the ways that they use the net, and 
there are huge numbers of applications that may or may not use HTTP as a 
base.

Also, the amount of traffic measured in any particular category should 
not be taken as an indication of the value of that kind of traffic.

Finally, traffic measurements made at popular sites (like search 
engines) shouldn't be taken as an indication of overall traffic.

> relay.

No, it moves the problem by trading one form of IPv6 breakage for 
another.   Furthermore, an ISP cannot "disable" 6to4 - there is no 
mechanism to do that.   If a customer is configured to use 6to4, it will 
keep trying to use 6to4 even if the ISP blocks the route.

The only things an ISP can do about 6to4 are:

  * provide a better form of IPv6 access (native, 6rd, configured
    tunnel, whatever),
  * provide a working outbound 6to4 relay, and/or
  * break it in a different (generally worse) way than it's broken already

Keith

---

From: Michael H Lambert <[email-masked]>
Date: Thu, 20 Nov 2014 10:52:46 -0500

On 20 Nov 2014, at 10:41, Keith Moore <[email-masked]> wrote:

> 	• provide a better form of IPv6 access (native, 6rd, configured tunnel, whatever),
> 	• provide a working outbound 6to4 relay, and/or
> 	• break it in a different (generally worse) way than it's broken already

And educate their users, which, admittedly, is something most everyone involved in operational networking (including myself) tries to avoid.

Michael

---

From: Philip Homburg <[email-masked]>
Date: Thu, 20 Nov 2014 17:27:58 +0100

>there are huge numbers of applications that may or may not use HTTP as a 

If we define 'ordinary user' as a user who is responsible for his network
infrastructure, but has no clue about what a network really is (i.e. 
exclude any kind of network managed by professionals)

then can you please give examples of what kind of IPv6-only resources that
ordinary user needs to access?

Around me, that just doesn't happen. But maybe other parts of the world
are more advanced.

>  * provide a better form of IPv6 access (native, 6rd, configured

Well, maybe ISPs should start right here. If users need access to IPv6-only
resources, then this is the right place to start. 

If users call their ISPs to ask about 6to4, then that should be clue that
something is missing in the services that the ISP provides.

---

From: Keith Moore <[email-masked]>
Date: Thu, 20 Nov 2014 11:38:01 -0500

> ordinary user needs to access?

Stop thinking only in terms of ordinary, or typical, users.   They 
aren't the only ones who matter, not the only ones whose use of the 
network is important.

> something is missing in the services that the ISP provides.
Absolutely.   The best possible answer is "You probably don't need to 
use 6to4 anymore, since we now support native IPv6."

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Nov 2014 08:47:13 +1300

Dan,

> To my knowledge Google is not really IPv6 only.  Nearly all of the population that relies on 6to4 anycast for access to IPv6 only content is likely to use IPv4 instead of IPv6 when attempting to re…

On balance I think it's indicative of people still running RFC 3484 policy,
since those with an updated policy would be unlikely to reach Google
via 6to4. So I agree with the view that those people would experience
timeouts that they don't experience today, if the anycast address became
unreachable.

    Brian

---

From: Gert Doering <[email-masked]>
Date: Fri, 21 Nov 2014 10:50:24 +0100

Hi,

> One thing I'm fairly confident about: an ISP has no business deliberately breaking anycast 6to4 router service for customers to whom it doesn't offer an alternative form of v6 access.

This I strongly agree to.

(Just for the record, I don't disagree with Keith on principle :) ).

Gert Doering
        -- NetMaster

---

From: Sander Steffann <[email-masked]>
Date: Fri, 21 Nov 2014 13:25:45 +0100

Hi,

> Op 21 nov. 2014, om 10:50 heeft Gert Doering <[email-masked]> het volgende geschreven:
> 
> Hi,
> 

+1

In case it wasn't clear: I think we shouldn't actively start breaking 6to4. If people want to run a public 6to4 relay that is fine. For me the deprecation is much more about informing the users: making it very clear that this is not a technology that is suitable for serious IPv6 deployments (and yes, unfortunately such users still exist).

In short: using 6to4 is a bad idea but facilitating it by providing relays is fine. We'll always have some legacy stuff on the internet. Their usage will just disappear over time.

Cheers,
Sander

---

From: David Farmer <[email-masked]>
Date: Mon, 24 Nov 2014 12:19:21 -0600

> believe it to be of operational utility, that is also an important

I support this document.  It needs to be made abundantly clear that use 
of 6to4 Anycast relays is not the way forward in almost all cases.  But, 
we are not making any recommendation against 6to4 in general. So, we 
need to find the right balance of language regarding not breaking 6to4 
that is actually working while allowing a clean and orderly shutdown of 
anycast relays over time.  In particular I feel language explicitly 
permitting network operators to filter out bad Anycast relays is also 
necessary.  I'm not comfortable with the only recommendations being 
directed toward relay operators.

It should be noted one of the several flaws in 6to4's design is there 
doesn't seem to be a good way for a network operator to check the health 
and proper functioning of a relay, either an anycast relay or a return 
relay.

In the discussion of this document I think there may be a general 
misunderstanding of the word "Deprecation" by many involved.

http://en.wikipedia.org/wiki/Deprecation

It does NOT mean removal with extreme prejudices, to the contrary, it 
simply mean recommending against some practice while still allowing it 
for backward compatibility.

So, deprecation of Anycast 6to4 relays doesn't mean they should 
necessarily go away anytime soon.  But, elimination of unused, under 
utilized, malfunctioning, and/or unsupported Anycast 6to4 relays is 
consistent with deprecation.  One wouldn't expect additional investment 
in Anycast 6to4 relays in the long-term either, because of deprecation.

Thanks.

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 Nov 2014 14:06:43 -0500

On 11/24/2014 01:19 PM, David Farmer wrote:
> consistent with deprecation.  One wouldn't expect additional 
> investment in Anycast 6to4 relays in the long-term either, because of 
> deprecation.

Perhaps it's simpler if we avoid using forms of the word "deprecate", 
and instead explain which practices are now recommended, not 
recommended, or discouraged.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 25 Nov 2014 08:19:17 +1300

> recommended, or discouraged.

The draft does that, IMHO quite clearly, and as far as I can see
there is no instance in the text where the string "deprecat" leads
to any ambiguity of interpretation. In particular:

   The guidelines in Section 4 of [RFC6343] remain valid for those who
   choose to continue operating Anycast 6to4 despite its deprecation.

(And SHOULD NOT or NOT RECOMMENDED are very much consistent with the
meaning of deprecation that David cited.)

   Brian

---

From: David Farmer <[email-masked]>
Date: Mon, 24 Nov 2014 13:35:32 -0600

> meaning of deprecation that David cited.)

I generally agree that the uses of "deprecate" and the recommendations 
are generally consistent with the reference that I provided.  With the 
possible exception of the recommendation to filter 192.88.99.0/24, and 
alternatives to this language are being discussed.

I wasn't suggesting that we not use "deprecate", but that we make sure 
everyone understands its meaning and therefore the intent of the 
document, which I believe is properly the "deprecation" of Anycast 6to4 
relays.

Thanks.