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

From: Ronald Bonica <[email-masked]>
Date: Sat, 2 Jul 2011 12:36:05 -0400

Folks,

Whereas there has been considerable controversy regarding draft-ietf-v6ops-6to4-to-historic, the v6ops chairs and document author have agreed to the following course of action:

- the V6OPS WG will withdraw its request to publish draft-ietf-v6ops-6to4-to-historic
- The author will introduce a new draft, intended for standards track publication. The new draft will update RFCs 3056 and 3068. It will say that if 6-to-4 is implemented, it must be turned off by default. 
- In order for the new draft to be published, it must achieve both V6OPS WG and IETF consensus

If anyone objects to this course of action, please speak up soon.

                                                    Ron
                                                    <Speaking as OPS Area AD>

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 2 Jul 2011 20:54:50 +0200

> If anyone objects to this course of action, please speak up soon.

Great, back to square one.

Is the reasoning behind the decision explained somewhere? My reading of the
threads on the subject in v6ops was that the opposition to 6to4-historic was
a small but vocal minority, and I thought that qualified as rough consensus.
But perhaps I missed some discussion.

Also, why do the author and the chairs think that the new draft will do any
better than 6to4-historic? I would assume that the same people who spoke up
against 6to4-historic will speak up against the new document, and since that
level of opposition was sufficient to prevent the publication
of 6to4-historic, it may be sufficient to prevent publication of the new
document as well. If so, we will have spent 3-6 months arguing about it for
naught.

Please, nobody answer this question with "welcome to the IETF" :-)

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 2 Jul 2011 12:21:36 -0700

On Jul 2, 2011 11:55 AM, "Lorenzo Colitti" <[email-masked]> wrote:
> Is the reasoning behind the decision explained somewhere? My reading of
the threads on the subject in v6ops was that the opposition to 6to4-historic
was a small but vocal minority, and I thought that qualified as rough
consensus. But perhaps I missed some discussion.

I saw the same thing. It is a shame that work that directly removes barriers
to REAL ipv6 deployment gets shouted down by a few people not involved in
REAL ipv6 deployment.

Welcome to the ietf indeed.

Cb

> Also, why do the author and the chairs think that the new draft will do
any better than 6to4-historic? I would assume that the same people who spoke
up against 6to4-historic will speak up against the new document, and since
that level of opposition was sufficient to prevent the publication
of 6to4-historic, it may be sufficient to prevent publication of the new
document as well. If so, we will have spent 3-6 months arguing about it for
naught.
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 02 Jul 2011 21:28:22 +0200

Very well said Lorenzo.

+1

Unless Ron describes exactly one by one real reasons to give up on 
draft-ietf-v6ops-6to4-to-historic and majority of v6ops WG agrees with 
those reasons IMHO the document should proceed as is.

 > It will say that if 6-to-4 is implemented, it must be turned
 > off by default.

Last ... if something is turned on or off by default is an 
implementation choice and last time I checked IETF was not in business 
to mandate any implementation choice.

Thx,
R.

> On Sat, Jul 2, 2011 at 6:36 PM, Ronald Bonica <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> the threads on the subject in v6ops was that the opposition to
> 6to4-historic was a small but vocal minority, and I thought that
> qualified as rough consensus. But perhaps I missed some discussion.
>
> any better than 6to4-historic? I would assume that the same people who
> spoke up against 6to4-historic will speak up against the new document,
> and since that level of opposition was sufficient to prevent the
> publication of 6to4-historic, it may be sufficient to prevent
> publication of the new document as well. If so, we will have spent 3-6
> months arguing about it for naught.
>

---

From: Keith Moore <[email-masked]>
Date: Sat, 2 Jul 2011 16:02:47 -0400

> Is the reasoning behind the decision explained somewhere? My reading of the threads on the subject in v6ops was that the opposition to 6to4-historic was a small but vocal minority, and I thought that qualified as rough consensus. 

Even if there was rough consensus within v6ops, rough consensus of v6ops does not equate to rough consensus of the entire IETF community. 

> Also, why do the author and the chairs think that the new draft will do any better than 6to4-historic? I would assume that the same people who spoke up against 6to4-historic will speak up against the new document, and since that level of opposition was sufficient to prevent the publication of 6to4-historic, it may be sufficient to prevent publication of the new document as well. If so, we will have spent 3-6 months arguing about it for naught.

I hope that the author(s) of the new document and the v6ops WG will understand that their task is to craft a document that can earn community-wide consensus, not merely the approval of v6ops.  As long as the document is brief and to-the-point, I don't see any problem.  I personally don't have any objection to the notion that 6to4 should be off by default and should require explicit configuration to enable it.

Keith

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 02 Jul 2011 22:22:42 +0200

Hi Keith,

> I personally don't have any objection to the notion that 6to4 should
> be off by default and should require explicit configuration to enable
> it.

Is there any feature (perhaps other then netboot) on commercial or open 
source routers which is not off by default and which would require 
explicit configuration to enable it ?

Thx,
R.

---

From: Keith Moore <[email-masked]>
Date: Sat, 2 Jul 2011 16:25:36 -0400

On Jul 2, 2011, at 4:22 PM, Robert Raszuk wrote:

> Is there any feature (perhaps other then netboot) on commercial or open source routers which is not off by default and which would require explicit configuration to enable it ?

I have understood that in the past there were a few routers that enabled 6to4 by default, though I don't know whether this is the case any longer.   
I also believe that there are currently hosts that enable 6to4 by default if there is no native v6 connectivity and the host has a public IPv4 address.

Keith

---

From: Philip Homburg <[email-masked]>
Date: Sat, 02 Jul 2011 23:18:52 +0200

In your letter dated Sat, 2 Jul 2011 16:02:47 -0400 you wrote:
>threads on the subject in v6ops was that the opposition to 6to4-historic was a
> small but vocal minority, and I thought that qualified as rough consensus. 
>
>Even if there was rough consensus within v6ops, rough consensus of v6ops does 
>not equate to rough consensus of the entire IETF community. 

Is there any summary of the IETF community consensus? 

I sort of can't imagine that ISPs want to continue operating 6to4 relays
longer than strictly necessary. So I'm curious what the IETF community at
large considers the future of 6to4 in it's default-disabled mode.

---

From: Randy Bush <[email-masked]>
Date: Sun, 03 Jul 2011 06:35:03 +0900

>> If anyone objects to this course of action, please speak up soon.

i object.  as measured on the real internet, not the ietf bar, 6to4
sucks caterpillar snot.  it is damaging to the users and to the users'
view of ipv6.

> a small but vocal minority, and I thought that qualified as rough consensus.

perhaps that minority was also vocal in the back room

> against 6to4-historic will speak up against the new document,

yes, but that will be a year from now.  in the ietf, delay is one form
of death.

> Please, nobody answer this question with "welcome to the IETF" :-)

this is nutso.  but this is normal.

welcome to the ietf

randy

---

From: Mark Smith <[email-masked]>
Date: Sun, 3 Jul 2011 10:08:44 +0930

On Sat, 2 Jul 2011 20:54:50 +0200

> document as well. If so, we will have spent 3-6 months arguing about it for

I don't object to what has been proposed, yet I object to
"6to4-historic" because I'm an extremely happy anycast 6to4 user and
have been for many years (I just recently looked at the date in the
script I wrote to bring it up, and was quite surprised it was dated
2002). 

Unfortunately people do judge books by their cover - if there is an RFC
that says 6to4 is historic, people would likely consider it something
that can't be used. We know it can operate correctly and reliably if it
is configured correctly. If the criteria for declaring a
technology historic is that some people can't operate it correctly and
reliably, then they'll have to be plenty of other -historic RFCs.

Perhaps declaring 6to4 deprecated rather than historic would have a
better chance of consensus.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 3 Jul 2011 03:03:15 +0200

On Sun, Jul 3, 2011 at 2:38 AM, Mark Smith <
[email-masked]> wrote:

> We know it can operate correctly and reliably if it
> is configured correctly.

... and in networks where there are public IP addresses and no firewalling,
and... etc. etc.

But we already had this discussion on v6ops, and since the consensus of the
WG was that the draft should be published, there's no point having it again.

---

From: Doug Barton <[email-masked]>
Date: Sat, 02 Jul 2011 18:04:27 -0700

On 07/02/2011 12:21, Cameron Byrne wrote:
>
> On Jul 2, 2011 11:55 AM, "Lorenzo Colitti" <[email-masked]
> <mailto:[email-masked]>> wrote:
>  >
>  > Is the reasoning behind the decision explained somewhere? My reading
> of the threads on the subject in v6ops was that the opposition to
> I saw the same thing. It is a shame that work that directly removes
> barriers to REAL ipv6 deployment gets shouted down by a few people not
> involved in REAL ipv6 deployment.

I can't speak to the "REAL" bit, but I agree that this is a very 
disappointing turn of events. Consensus is not the same as "universal 
agreement," and I don't think the fact that a few people are repeating 
the same marginally-relevant-at-best points over and over again should 
have sidetracked this process.

Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: Erik Kline <[email-masked]>
Date: Sun, 3 Jul 2011 10:10:03 +0900

All,

> better chance of consensus.

Pardon my ignorance, but where is the document describing the
implications of historic{,al} vs deprecated?

This (http://tools.ietf.org/html/rfc2026#section-4.2.4) is well known:

"""
   A specification that has been superseded by a more recent
   specification or is for any other reason considered to be obsolete is
   assigned to the "Historic" level.  (Purists have suggested that the
   word should be "Historical"; however, at this point the use of
   "Historic" is historical.)

   Note: Standards track specifications normally must not depend on
   other standards track specifications which are at a lower maturity
   level or on non standards track specifications other than referenced
   specifications from other standards bodies.  (See Section 7.)
"""

I don't know where similar explanatory language about "Deprecated"
might be (I'm sure I just didn't search correctly or long enough).

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 3 Jul 2011 03:10:15 +0200

On Sat, Jul 2, 2011 at 10:02 PM, Keith Moore <[email-masked]>wrote:

> consensus.
> Even if there was rough consensus within v6ops, rough consensus of v6ops
> does not equate to rough consensus of the entire IETF community.
>

And who says that "rough consensus of the entire IETF community" is that
this draft should not be published? Were there public discussions to that
effect that came to this conclusion?

---

From: Randy Bush <[email-masked]>
Date: Sun, 03 Jul 2011 10:47:13 +0900

> And who says that "rough consensus of the entire IETF community" is
> that this draft should not be published? Were there public discussions
> to that effect that came to this conclusion?

that is usually determined when the iesg last calls the document after
the wg has passed it to the iesg.

the ipv6 heads are amazingly immune to reality.

6to4 has been measured and clearly demonstrated to have failed in the
field.  yes, it could work.  but it doesn't.  we need to get over it.

randy

---

From: Mark Smith <[email-masked]>
Date: Sun, 3 Jul 2011 11:20:48 +0930

On Sat, 2 Jul 2011 12:21:36 -0700
Cameron Byrne <[email-masked]> wrote:

> to REAL ipv6 deployment 

Where is the evidence that 6to4 is holding back native IPv6 
deployment?

> gets shouted down by a few people not involved in
> REAL ipv6 deployment.
> 

How do you know that?

---

From: Mark Smith <[email-masked]>
Date: Sun, 3 Jul 2011 11:24:20 +0930

On Sun, 3 Jul 2011 10:10:03 +0900

> might be (I'm sure I just didn't search correctly or long enough).

Since 6rd depends on 6to4, as it is a variant of it, would 6to4 being
declared historic also mean that 6rd needs to become historic as well?

---

From: Erik Kline <[email-masked]>
Date: Sun, 3 Jul 2011 11:00:37 +0900

> declared historic also mean that 6rd needs to become historic as well?

http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-05
Section 1, in which the draft clarifies that 6rd supersedes 6to4,
which meets the qualification in the first paragraph of the "Historic"
term.  With 6rd we clearly don't need to have anything built on top of
6to4 in the future, addressing the 2nd paragraph.

---

From: Ronald Bonica <[email-masked]>
Date: Sat, 2 Jul 2011 22:22:32 -0400

Lorenzo,

You pose very reasonable questions.  I will try to reiterate them:

1)      What are the criteria for determining consensus? What makes you think that there was no consensus on 6-to-4-historic?

2)      What makes you think that the new draft is just as good?

3)      What makes you think that the new draft will do any better than 6-to-4-historic?

Responses follow:

1)      Because we do not vote in the IETF, the process for determining consensus is squishy. A simple majority does not win the day. A few strongly held objections backed by even a scintilla of technical rational can increase the size of the super-majority required to declare consensus. While it was not clear that the IETF has achieved consensus regarding 6-to-4-historic, it also was not clear that the IETF had not achieved consensus.  In this case, we had a choice between spending cycles arguing about consensus, or finding a solution that everybody could live with.

2)      IMHO, the new draft will not be as good as 6-to-4-historic. However, it solves the operational problem by disabling 6-to-4 by default. That's much better than nothing.

3)      I have been working behind the scenes with a few of those who objected to 6-to-4-historic. They didn't object to the new draft. However, I invite those people to speak for themselves.

                                                                                                             Ron

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Saturday, July 02, 2011 2:55 PM
To: Ronald Bonica
Cc: [email-masked]; IETF Discussion
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic

On Sat, Jul 2, 2011 at 6:36 PM, Ronald Bonica <[email-masked]<mailto:[email-masked]>> wrote:
- In order for the new draft to be published, it must achieve both V6OPS WG and IETF consensus

Is the reasoning behind the decision explained somewhere? My reading of the threads on the subject in v6ops was that the opposition to 6to4-historic was a small but vocal minority, and I thought that qualified as rough consensus. But perhaps I missed some discussion.

---

From: "Frank Bulk" <[email-masked]>
Date: Sat, 2 Jul 2011 21:27:21 -0500

Yes, the Linksys E2000, E3000, E4200, WRT610N, and a small batch of Apple
Airports had 6to4 on by default, but the latest firmware versions turn that
off.  

Frank

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Keith Moore
Sent: Saturday, July 02, 2011 3:26 PM
To: [email-masked]
Cc: [email-masked]; IETF Discussion
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic

> Is there any feature (perhaps other then netboot) on commercial or open
source routers which is not off by default and which would require explicit
configuration to enable it ?

I have understood that in the past there were a few routers that enabled
6to4 by default, though I don't know whether this is the case any longer.   
I also believe that there are currently hosts that enable 6to4 by default if
there is no native v6 connectivity and the host has a public IPv4 address.

Keith

---

From: Doug Barton <[email-masked]>
Date: Sat, 02 Jul 2011 19:39:05 -0700

On 07/02/2011 19:22, Ronald Bonica wrote:
> 1)Because we do not vote in the IETF, the process for determining
> consensus is squishy. A simple majority does not win the day. A few
> strongly held objections backed by even a scintilla of technical
> rational can increase the size of the super-majority required to declare
> consensus. While it was not clear that the IETF has achieved consensus
> regarding 6-to-4-historic, it also was not clear that the IETF had not
> achieved consensus.  In this case, we had a choice between spending
> cycles arguing about consensus, or finding a solution that everybody
> could live with.

IMO that is the wrong goal. Consensus does not mean universal agreement. 
Trying to get "a solution that everybody could live with" all too often 
results in a product with no operational value.

Doug

--

---

From: Doug Barton <[email-masked]>
Date: Sat, 02 Jul 2011 19:44:24 -0700

> Where is the evidence that 6to4 is holding back native IPv6

It's been discussed ad nauseum in numerous fora. Bad 6to4 (which almost 
all of it is) results in a poor user experience when the largest content 
providers enable AAAA records. Thus, they are less inclined to enable them.

I realize that there are a lot of people that dismiss both the evidence 
that's been put forward and the rationale, but it's been presented and 
discussed pretty thoroughly.

Doug

--

---

From: Keith Moore <[email-masked]>
Date: Sat, 2 Jul 2011 23:10:47 -0400

On Jul 2, 2011, at 3:21 PM, Cameron Byrne wrote:
> I saw the same thing. It is a shame that work that directly removes barriers to REAL ipv6 deployment gets shouted down by a few people not involved in REAL ipv6 deployment
> 

I find myself wondering what you mean by REAL IPv6.  For me, REAL IPv6 is code that uses the IPv6 programming model, 128 bit addresses, end-to-end transparency, no NATs.  6to4 certainly qualifies.

Keith

---

From: Keith Moore <[email-masked]>
Date: Sat, 2 Jul 2011 23:11:43 -0400

On Jul 2, 2011, at 9:10 PM, Lorenzo Colitti wrote:

> On Sat, Jul 2, 2011 at 10:02 PM, Keith Moore <[email-masked]> wrote:
> And who says that "rough consensus of the entire IETF community" is that this draft should not be published? Were there public discussions to that effect that came to this conclusion?

There's clearly a lack of consensus to support it.

Keith

---

From: Keith Moore <[email-masked]>
Date: Sat, 2 Jul 2011 23:14:53 -0400

> Section 1, in which the draft clarifies that 6rd supersedes 6to4,

which is of course completely incorrect.

Keith

---

From: Keith Moore <[email-masked]>
Date: Sat, 2 Jul 2011 23:20:37 -0400

On Jul 2, 2011, at 10:39 PM, Doug Barton wrote:

> IMO that is the wrong goal. Consensus does not mean universal agreement. Trying to get "a solution that everybody could live with" all too often results in a product with no operational value.

IMO you're thinking about this the wrong way.  if a document is to be published with IETF's imprimatur, it needs to adhere to IETF's rules.  Those rules require, for a standards action, at least rough community-wide consensus.  

When a narrowly focused working group declares consensus within itself, that clearly doesn't speak for the whole IETF.  The fact that the consensus was quite rough even within the v6ops group should have been understood as a sign that the proposed action might not win consensus overall - especially given that several of the objections came from non-operators who are not well represented in v6ops.

Keith

---

From: Melinda Shore <[email-masked]>
Date: Sat, 02 Jul 2011 19:08:52 -0800

> results in a product with no operational value.

"Everybody can live with" is pretty much the universal operating
definition of "consensus" in organizations that use consensus
decision-making.  I've got some concerns, as well, that effort
is being put into technologies that there's no incentive to use,
but in terms of *process* Ron is spot-on.

Melinda

---

From: "Michel Py" <[email-masked]>
Date: Sat, 2 Jul 2011 20:21:47 -0700

Subject to reading the not-available-yet text, I support this approach.
It appears to be reasonable political compromise.

Michel.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ronald Bonica
Sent: Saturday, July 02, 2011 9:36 AM
To: [email-masked]; IETF Discussion
Subject: draft-ietf-v6ops-6to4-to-historic

Folks,

Whereas there has been considerable controversy regarding
draft-ietf-v6ops-6to4-to-historic, the v6ops chairs and document author
have agreed to the following course of action:

- the V6OPS WG will withdraw its request to publish
draft-ietf-v6ops-6to4-to-historic
- The author will introduce a new draft, intended for standards track
publication. The new draft will update RFCs 3056 and 3068. It will say
that if 6-to-4 is implemented, it must be turned off by default. 
- In order for the new draft to be published, it must achieve both V6OPS
WG and IETF consensus

                                                    Ron
                                                    <Speaking as OPS
Area AD>
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Ronald Bonica <[email-masked]>
Date: Sat, 2 Jul 2011 23:31:55 -0400

Randy,

You have three points that deserve to be addressed. These are:

1) "as measured on the real internet, not the ietf bar, 6to4 sucks caterpillar snot"
2) "perhaps that minority was also vocal in the back room"
3) "yes, but that will be a year from now.  in the ietf, delay is one form of death"

Responses follow:

1) While not stated so colorfully, draft-ietf-v6ops-6to4-advisory made this point. It has been approved for publication.
2) While there was no back-room activity, an appeal had been filed at the WG level. Since WG consensus was stronger than IETF consensus, it is reasonable to assume that the appeal would be escalated to the IESG level if it was not approved at the WG level. So, any way you look at it, there would be delays.
3) The new document may not take a year to publish. Since it is a short draft, it could be produced in a few days. Once it is produced, we could immediately initiate a WG last call and an IETF last call immediately after that. So, we might be talking about a six-week delay.

Now, I have a question for you, Lorenzo and Doug. If our goal is to take 6-to-4 off of the Internet, does not disabling it by default solve most of the problem? AFAIKS, very few users would enable it and service providers would not be economically incented to support 6-to-4 relay routers. 

Comments?

                                    Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Randy Bush
Sent: Saturday, July 02, 2011 5:35 PM
To: Lorenzo Colitti
Cc: IPv6 Ops WG; IETF Discussion
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic

welcome to the ietf

randy

---

From: Joel Jaeggli <[email-masked]>
Date: Sat, 2 Jul 2011 20:40:51 -0700

> which is of course completely incorrect.

While 6rd shares a mechanism with 6 to 4 and can be implemented by reusing code, it is a mistake to conclude a standards action that impacts the later would impact the former, or that they are substitutable for each other.

---

From: Mark Smith <[email-masked]>
Date: Sun, 3 Jul 2011 13:19:13 +0930

On Sat, 02 Jul 2011 19:44:24 -0700
Doug Barton <[email-masked]> wrote:

> It's been discussed ad nauseum in numerous fora.

Discussion isn't evidence, as people usually don't post any data to
support their assertions.

Since posting that question I remembered RFC6036 -
"Emerging Service Provider Scenarios for IPv6 Deployment". Here's what
is says about ISPs' views on 6to4. I don't think it supports the
assertion that 6to4 is holding back native deployment -

"2.5.  IPv6 Technologies

   Turning to technology choices, the overwhelming choice of approach
   (94%) is a dual-stack routing backbone, and the reason given is
   simplicity and cost. 39% run, or plan to run, a 6to4 relay as well,
   and 16% run or plan a Teredo server. "

"Diffusions of Innovations" discusses attributes of innovations that
influence their adoption. One of those attributes is trialability,
meaning how hard or easy is it to trial the innovation. If a
innovation requires a high level of commitment to trial, then it is
less likely to be trialed and therefore adopted. Once an residential
ISP as IPv6 transit, 6to4 is a simple and much lower cost way of
trialing IPv6 services and gaining experience with IPv6, before and
during the development and deployment of native IPv6 services and the
required supporting infrastructure, such as AAA, helpdesk training etc.

Declaring 6to4 to be historic might encourage native IPv6 deployment,
but I think it will also make trialing IPv6 much harder.

 Bad 6to4 (which almost 
> providers enable AAAA records. Thus, they are less inclined to enable them.

The involvement in World IPv6 day by large content providers and the
apparent lack of significant problems would be suggest the opposite is
now the case. Google continuing to provide youtube video content to 6to4
tunnel users (such as myself), nearly a month later, suggests that any
problems with it are tractable. 6to4 users are easy to spot by the
2002::/16 prefix, so if Google needed to they could probably quite
easily limit their IPv6 content delivery to native only IPv6 users.
So, in other words, Google now consider 6to4 to be reliable enough to
continue to deliver content using it for one of their high profile
content sites.

> discussed pretty thoroughly.

In Geoff Huston's report (Dec 2010), he says that he measured a 13%
failure rate with 6to4. A number of things have happened since then -
IANA has run out of IPv4 addresses, and World IPv6 day. Those two
events have increased the interest in IPv6 (the residential IPv6 trial
I was working on gained more participants due to these events),
which would have created an incentive for people to improve the quality
of their 6to4 operation, or possibly deploy a trial 6to4 relay. An
update on that data would be useful.

Regards,
Mark.

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 2 Jul 2011 21:02:02 -0700

On Sat, Jul 2, 2011 at 8:10 PM, Keith Moore <[email-masked]> wrote:
> REAL ipv6 deployment
> I find myself wondering what you mean by REAL IPv6.  For me, REAL IPv6 is
> code that uses the IPv6 programming model, 128 bit addresses, end-to-end
> transparency, no NATs.  6to4 certainly qualifies.

That's not what it means to me.  REAL IPv6 is a replacement for IPv4
and can address greater than 100s of billions of endpoint and is
suitable for very large traffic loads.  As an access network provider,
i need content on native IPv6.  It does not make sense to anyone in my
organization or industry to deploy IPv6 unilaterally.  There is no
benefit in this approach vs just doing NAT444.  If there is IPv6
content on a meaningful scale ( by the numbers that means for "my
network": Google, Facebook, Yahoo and their CDNs ...), then i have a
solid business case for IPv6 access networks. Full Stop.

If the content guys say 6to4 is a pain, and they do, then i need to
help them find a way to solve that pain.  I operate in an address
exhausted world, so NAT44 is my only IPv4 tool for growth.

In the meantime, i null route the 6to4 anycast address because it
creates half open state in my CGN.  Been doing that for at least 5
years.  My next step is filtering AAAA over IPv4 access because 6to4
client brokeness won't die on its own, that will be rolled out in a
few months.  Operating a network means making the tweeks that keep the
wheels rolling, and we don't find many technology purist in my line of
work.

Other access providers like 6to4 so much that they want to NAT it.
This is the reason why historic is the proper term.

http://tools.ietf.org/html/draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-02

I look forward to that discussion on ietf@

Cameron

---

From: Doug Barton <[email-masked]>
Date: Sat, 02 Jul 2011 21:26:34 -0700

On 07/02/2011 20:31, Ronald Bonica wrote:
> 2) While there was no back-room activity,

You yourself mentioned that you were in private discussion with some who 
objected to the "historic" draft. There's nothing wrong with that, it's 
how the world works, and personally I would expect it of you. But please 
don't then turn around and say that it's not happening. :)

> an appeal had been filed at the WG level. Since WG consensus was stronger than IETF consensus, it is reasonable to assume that the appeal would be escalated to the IESG level if it was not approved at the WG level. So, any way you look at it, there would be delays.

Speaking for myself, my goal is not to take STF off the Internet. My 
goal is to do everything we can to get the best possible IPv6 deployed 
in the most places as fast as possible. STF is a hindrance to that goal, 
so I'd like it to go away.

As I've said in the past, I was in the extreme wing of the WG that would 
have preferred to that we came down on the "turn it off, yesterday" 
side. So can I accept "off by default on the client side" as a step in 
the right direction? Sure, why not. But as others have pointed out the 
difference between that and "historic" is that the latter gives vendors 
active DIScouragement to support it at all. IMO that would be better. 
Much better.

Hope I answered your question,

Doug

--

---

From: Keith Moore <[email-masked]>
Date: Sun, 3 Jul 2011 00:39:56 -0400

> solid business case for IPv6 access networks. Full Stop.

Chicken-and-egg.  You can't justify widespread deployment of IPv6 until there are a lot of content/people/applications using it, and there won't be a lot of content/people/applications using it until it's widely available.

The whole purpose of mechanisms like 6to4 is to help break that logjam.  We need to fix the existing mechanisms, and/or provide better ones, rather than killing things that work... even if they only work in corner cases.

(Basing the argument entirely on "content", IMO, is misguided, because it neglects significant potential drivers of IPv6 adoption, and because there's still no incentive to move to v6 as long as the same content is available on v4.)

> help them find a way to solve that pain.  

So you want to help the "content" guys at the expense of other legitimate uses of 6to4.   Frankly, I don't think that's reasonable.  The net doesn't exist just for content delivery.

> few months.

So you admit you're sabotaging the network?

Keith

---

From: Keith Moore <[email-masked]>
Date: Sun, 3 Jul 2011 00:41:07 -0400

On Jul 3, 2011, at 12:26 AM, Doug Barton wrote:

> Speaking for myself, my goal is not to take STF off the Internet. My goal is to do everything we can to get the best possible IPv6 deployed in the most places as fast as possible. STF is a hindrance to that goal, so I'd like it to go away.

STF is also helping that goal. 

Keith

---

From: Mark Smith <[email-masked]>
Date: Sun, 3 Jul 2011 14:15:19 +0930

On Sat, 2 Jul 2011 21:02:02 -0700
Cameron Byrne <[email-masked]> wrote:

<snip>
> years.

So, to be clear, you're not making an observation that 6to4 is broken,
based on measurement or actual use, you're actively breaking it.

>  My next step is filtering AAAA over IPv4 access because 6to4

I think the root cause of your issues is the deployment of IPv4 CGN in
the first place before IANA and the RIRs ran out of IPv4 addresses by
the sounds of it. I think then means that any protocol that your
customers try to use that would create unwanted state in your IPv4 CGN
should be, by your definition, declared "historic", not just 6to4. When
a customer signs up to your service, are they informed as to which
protocols and applications they are allowed to use? My opinion is that
if there are restrictions on what protocols and applications customers
can operate then their service is not a real Internet service. The
majority of, if not all, residential broadband service providers in my
market hold the same belief - it seems to be the "pure" mobile
carriers that commonly don't.

---

From: Joel Jaeggli <[email-masked]>
Date: Sat, 2 Jul 2011 21:59:24 -0700

This line of discussion is not productive... 

Between them the 4 largest north american wireless carriers need ~18 /8s to assign public ipv4 addresses to their wireless cpe... they don't have that and there's no-where to get it, then there's the rest of the world.

---

From: Randy Bush <[email-masked]>
Date: Sun, 03 Jul 2011 14:06:36 +0900

> 1) While not stated so colorfully, draft-ietf-v6ops-6to4-advisory made
>    this point. It has been approved for publication. 

but then do we not draw the conclusion that therefore publishing
draft-ietf-v6ops-6to4-to-disgusting is the correct approach?

> 2) While there was no back-room activity, an appeal had been filed at
>    the WG level. Since WG consensus was stronger than IETF consensus,
>    it is reasonable to assume that the appeal would be escalated to
>    the IESG level if it was not approved at the WG level.

so these days people who do not get their way use the nuclear option?
we raised kids.  when those tactics resulted in "we are so sorry you do
not like the result, but that's the result" they soon stopped.

> So, any way you look at it, there would be delays.

welcome to the ietf, where process is our most important product.

> 3) The new document may not take a year to publish. Since it is a
>    short draft, it could be produced in a few days. Once it is
>    produced, we could immediately initiate a WG last call and an IETF
>    last call immediately after that. So, we might be talking about a
>    six-week delay.

so process this one in six weeks, please.

> Now, I have a question for you, Lorenzo and Doug. If our goal is to
> take 6-to-4 off of the Internet, does not disabling it by default
> solve most of the problem? AFAIKS, very few users would enable it and
> service providers would not be economically incented to support 6-to-4
> relay routers.

the economic incentive to half-assed service providers is that it gives
an excuse not to deploy ipv6.  the response of these folk will be web
pages instructing their users how to turn 6to4 on.

randy

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 3 Jul 2011 07:29:10 +0200

> There's clearly a lack of consensus to support it.

Nope. The v6ops chairs saw consensus in v6ops to support it. Can you point
to significant strength of opinion of the wider IETF community, but not in
v6ops, that has reason to oppose it? If all you can point to is the same
people that were opposing it in v6ops, then I think they don't count,
because the rough consensus in v6ops was that the document should be
published.

So, I ask again: where are the statements made in opposition of this
proposal made outside of v6ops? Can you point to them?

---

From: Keith Moore <[email-masked]>
Date: Sun, 3 Jul 2011 01:47:11 -0400

On Jul 3, 2011, at 1:29 AM, Lorenzo Colitti wrote:

> On Sun, Jul 3, 2011 at 5:11 AM, Keith Moore <[email-masked]> wrote:
> Nope. The v6ops chairs saw consensus in v6ops to support it. Can you point to significant strength of opinion of the wider IETF community, but not in v6ops, that has reason to oppose it?

That's not how it works.  You have to get consensus in IETF, not in v6ops.  (And it doesn't matter what you think of other people's reasons to oppose -historic.)

> If all you can point to is the same people that were opposing it in v6ops, then I think they don't count, because the rough consensus in v6ops was that the document should be published.

Your logic is flawed.   When you separately sample two dissimilar groups it isn't statistically valid to combine the two samples.   The correct way to think about it is that the consensus was very rough already in v6ops (even the official writeup says so), and it only moved further away from rough consensus when the comments from outside of v6ops were taken into account.

I agree that the people who objected on v6ops and also objected on the ietf list shouldn't be counted twice as opposing the standards action.   But when I did the tally, I found only a small amount of overlap between people opposing -historic in v6ops, and people opposing it on the ietf list.

> So, I ask again: where are the statements made in opposition of this proposal made outside of v6ops? Can you point to them?

Some of them were posted to the IETF list.  IESG may have received others privately.  That is permitted by our process.

Keith

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 3 Jul 2011 07:53:46 +0200

> but I think it will also make trialing IPv6 much harder.

We don't need to trial the IPv6 protocol. There are hundreds of thousands of
native users accessing production-grade IPv6 services, like Google's, every
day. We know the IPv6 protocol works. ISPs do need to trial IPv6 deployment.
But 6to4 does not help there, because 6to4 is not deployed by ISPs. They
will need to trial native deployments, or 6rd. If *users* want to trial IPv6
until native IPv6 is available, then they can use configured tunnels.

> problems with it are tractable.

I would assert that the problems with 6to4 are not tractable without
disabling 6to4. Our IPv6 brokenness statistics for before and after World
IPv6 Day are very similar.

> 6to4 users are easy to spot by the 2002::/16 prefix, so if Google needed to
> they could probably quite easily limit their IPv6 content delivery to native
> only IPv6 users.

No, that's not how it works. There is no problem with 6to4 when it works as
well as IPv4. The problem is that 6to4 only works *at all* (never mind works
"as well as IPv4") 80% of the time.

Unfortunately, in the 20% of the time that it's not working, Google has no
idea that the user has a 2002::/16 address. Google only knows, after the
fact, that the user suffered a 20 or 75-second timeout and was not happy. So
it would serve no purpose to avoid serving users that successfully connect
from 2002::/16 addresses; once the AAAA record is handed out, the damage is
done. What Google could do, however, is stop handing out AAAA records to
networks that have significant number of 6to4 users in the future. We're
considering this.

An update on that data would be useful.

As I said before, our data on IPv6 brokenness did not change significantly
after World IPv6 Day. Can you take that as a proxy that 6to4 has not
improved?

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 3 Jul 2011 07:58:58 +0200

On Sun, Jul 3, 2011 at 2:38 AM, Mark Smith <
[email-masked]> wrote:

> "6to4-historic" because I'm an extremely happy anycast 6to4 user

"It works for me, so there's obviously no problem". When you think of
6to4-historic, please think of the 20% of anycast 6to4 users that are
broken.

We know it can operate correctly and reliably if it is configured correctly.

But we also know that it's not configured correctly, to such an extent that
it does not work at all in 20% of cases (Geoff's data). And we know of no
reason why that would improve, though we do know of reasons why it would get
worse (e.g., due to ISPs giving bogon public space to their users).

---

From: Keith Moore <[email-masked]>
Date: Sun, 3 Jul 2011 02:27:13 -0400

On Jul 3, 2011, at 1:53 AM, Lorenzo Colitti wrote:

> On Sun, Jul 3, 2011 at 5:49 AM, Mark Smith <[email-masked]> wrote:
> We don't need to trial the IPv6 protocol. There are hundreds of thousands of native users accessing production-grade IPv6 services, like Google's, every day. We know the IPv6 protocol works. ISPs do need to trial IPv6 deployment. But 6to4 does not help there, because 6to4 is not deployed by ISPs.

6to4 allows applications to use IPv6 even when ISPs don't support it.   The idea is to allow application deployment, and use of IPv6, to develop independently of ISP deployment of native IPv6.

> They will need to trial native deployments, or 6rd. If *users* want to trial IPv6 until native IPv6 is available, then they can use configured tunnels.

Uh, no.  If you're an application developer, shipping code that requires every single user to set up a tunnel is a nonstarter.  And as well all know, configured tunnels often route very suboptimally.   In many cases 6to4 works better.

It's not as if the only applications that matter are those that are layered over HTTP.

> I would assert that the problems with 6to4 are not tractable without disabling 6to4. Our IPv6 brokenness statistics for before and after World IPv6 Day are very similar.

The only unfixable problem that 6to4 has is its inability to work with NATs, including LSN.     Some of those fixes would require code updates to host implementations, but disabling 6to4 would also require code updates.

> 6to4 users are easy to spot by the 2002::/16 prefix, so if Google needed to they could probably quite easily limit their IPv6 content delivery to native only IPv6 users.
> 
> No, that's not how it works. There is no problem with 6to4 when it works as well as IPv4. The problem is that 6to4 only works *at all* (never mind works "as well as IPv4") 80% of the time.

That figure is not based on a representative sample of all 6to4 use, so it's hard to know how much confidence to have in it.

Keith

---

From: Randy Bush <[email-masked]>
Date: Sun, 03 Jul 2011 15:29:39 +0900

>> Nope. The v6ops chairs saw consensus in v6ops to support it. Can you
>> point to significant strength of opinion of the wider IETF community,
>> but not in v6ops, that has reason to oppose it?
> 
> That's not how it works.  You have to get consensus in IETF, not in
> v6ops.

when it is last called.  and you can dos that mailing list then, and
threaten, and bluster.

randy

---

From: Keith Moore <[email-masked]>
Date: Sun, 3 Jul 2011 02:30:13 -0400

On Jul 3, 2011, at 1:58 AM, Lorenzo Colitti wrote:

> On Sun, Jul 3, 2011 at 2:38 AM, Mark Smith <[email-masked]> wrote:
> "It works for me, so there's obviously no problem". When you think of 6to4-historic, please think of the 20% of anycast 6to4 users that are broken.

6to4 used to be far less reliable than that, but has improved as additional relays were deployed.   It's reasonable to expect that the publication of -advisory will improve the situation further.

Keith

---

From: Ted Lemon <[email-masked]>
Date: Sun, 3 Jul 2011 02:37:43 -0400

> Some of them were posted to the IETF list.  IESG may have received others privately.  That is permitted by our process.

This is a frustrating conversation.   Everybody who supported the consensus in v6ops is an IETF participant, and their wishes count toward the IETF consensus.   The draft is good.   It encourages people to do the right things: keep 6to4 relays active, but not ship products with 6to4 enabled by default.  This works for everyone—for people like me who are using 6to4 for our IPv6 connectivity, it works because the relays stay up.   For people who do not have global IPv4 addresses, they do not wind up with IPv6 routes that go nowhere.   It certainly serves Keith Moore's needs, no matter how vehemently, nor how often, he may insist that it does not.

So this really does look like another IETF night of long knives, where a good draft gets scuttled in secret because a few very loud people manage to create enough of a fuss to make the person or persons calling the consensus feel like they're going to get fricasseed if they call the consensus in favor of the draft.

Have we actually had a formal consensus call for the IETF?   Who called the consensus?   Can we have a summary?   I haven't seen one.

---

From: Keith Moore <[email-masked]>
Date: Sun, 3 Jul 2011 02:55:42 -0400

On Jul 3, 2011, at 2:37 AM, Ted Lemon wrote:

> This is a frustrating conversation.   Everybody who supported the consensus in v6ops is an IETF participant, and their wishes count toward the IETF consensus.  

Yes their wishes do count.   But the consensus was marginal even in v6ops, and v6ops isn't representative of the breadth of interests in the entire IETF.   It should hardly be surprising that a very rough consensus within a working group doesn't translate to a rough consensus within IETF as a whole.

v6ops isn't special in this regard.  The same is true for any other working group.  Unfortunately, it's really easy for a working group that is focused on a particular set of concerns, to neglect concerns from the wider community.

> The draft is good.   It encourages people to do the right things: keep 6to4 relays active, but not ship products with 6to4 enabled by default.  This works for everyone—for people like me who are using 6to4 for our IPv6 connectivity, it works because the relays stay up.   For people who do not have global IPv4 addresses, they do not wind up with IPv6 routes that go nowhere.   It certainly serves Keith Moore's needs, no matter how vehemently, nor how often, he may insist that it does not.

You are not in a good position to evaluate what I need.

> So this really does look like another IETF night of long knives, where a good draft gets scuttled in secret because a few very loud people manage to create enough of a fuss to make the person or pe…

No, it's not a good draft.  It's misleading in many places.  And the label of Historic is simply inappropriate for something that is still quite useful for many people and for which no good replacement yet exists.  

The "right things" that you refer to get obscured by the overall message of the Historic label.  And the -advisory draft says the "right things" much better.

> Have we actually had a formal consensus call for the IETF?   Who called the consensus?   Can we have a summary?   I haven't seen one.

That's what the IETF Last Call was.   IESG is supposed to evaluate consensus as well as technical merit in its balloting.

Keith

---

From: Doug Barton <[email-masked]>
Date: Sat, 02 Jul 2011 23:58:54 -0700

On 07/02/2011 20:49, Mark Smith wrote:
> Doug Barton<[email-masked]>  wrote:
>

And yet, they did.

This whole thing is getting silly, and I'm tired of repeating myself. I 
think Lorenzo did a great job of explaining some more of the downsides 
of 6to4 and I don't have anything useful to add beyond what I've already 
said.

--

---

From: Mark Smith <[email-masked]>
Date: Sun, 3 Jul 2011 16:34:35 +0930

On Sat, 2 Jul 2011 21:59:24 -0700
Joel Jaeggli <[email-masked]> wrote:

> Between them the 4 largest north american wireless carriers need ~18 /8s to assign public ipv4 addresses to their wireless cpe...
> they don't have that and there's no-where to get it, then there's the
> rest of the world.

That's now, but what about when they chose to implement IPv4 CGN,
likely to be years ago.

Cameron is choosing to blame 6to4 for a problem that any of the
stateless and/or unidirectional Internet protocols could cause on a
IPv4 CGN. His arguments to make 6to4 historic are not based on issues
specific to 6to4. If 6to4 is made historic, does he then start lobbying
for UDP-historic?

---

From: SM <[email-masked]>
Date: Sat, 02 Jul 2011 23:29:58 -0700

At 21:59 02-07-2011, Joel Jaeggli wrote:
>Between them the 4 largest north american wireless carriers need ~18 
>/8s to assign public ipv4 addresses to their wireless cpe... they 
>don't have that and there's no-where to get it, then there's the 
>rest of the world.

http://aboba.drizzlehosting.com/IAB/arin.txt

Regards,
-sm

---

From: Keith Moore <[email-masked]>
Date: Sun, 3 Jul 2011 03:17:00 -0400

>> support their assertions.

I think it's been adequately supported that the interaction of 6to4 with (a) misconfigured relay routers and/or (b) protocol 41 filters, hinders one kind of native v6 deployment - i.e. providing the same content via both v4 and v6, where the client's host prefers v6 (including 6to4) destinations over v4 destinations.  There's clearly a disincentive to a content provider to advertise v6 addresses for its domains, if use of those v6 addresses will result in significantly slower or less reliable access for any significant set of users.   That much should be obvious.

However,  that's not the only kind of IPv6 deployment that matters.

Meanwhile misconfigured relay routers can be fixed, or their advertisements filtered; and hosts can and should be updated to prefer IPv4 destinations over 6to4 destinations.  6to4, even when enabled, should be a "last resort".  

All of these fixes should be implemented.  But that last fix alone should address (no pun intended) the v4/v6 content providers' concerns while still preserving use of 6to4 for cases where IPv6 is really needed.  And that last fix can be deployed much more quickly than the "nuclear option" of trying to get 6to4 support removed from products.

Keith

---

From: Randy Bush <[email-masked]>
Date: Sun, 03 Jul 2011 16:23:45 +0900

> of 6to4 and I don't have anything useful to add beyond what I've already 

geoff's presos show the 6to4 train wreck pretty clearly.  and it ain't
pretty.

yes, a few geeks such as rob austein, keith moore, ... who desperately
want to test ipv6 can manage to get it working.  big whoopie doo.  it is
a disaster for a significant percentage of the end users.  it needs to
be stopped.

randy

---

From: Gert Doering <[email-masked]>
Date: Sun, 3 Jul 2011 13:10:47 +0200

Hi,

> There's clearly a lack of consensus to support it.

There's two very vocal persons opposing it and a much larger number of
people that support it, but have not the time to write a similarily
large amount of e-mails.  For me, this is enough for "rough consensus".

(And I second everything Lorenzo, Randy and Cameron said - there's 
theoretical possibilities, and real world.  6to4 fails the real-world
test.  Get over it, instead of attacking people that run real-world
networks for the decisions they need to do to keep the networks running
in a world without enough IPv4 addresses).

Gert Doering
        -- Operator
-- 
did you enable 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 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Philip Homburg <[email-masked]>
Date: Sun, 03 Jul 2011 13:17:14 +0200

>networks that have significant number of 6to4 users in the future. We're

I think this clearly illustrates why the IETF should issue a strong statement
that no new 6to4 installation should be deplayed and the existing 6to4 users
should migrate to other tunneling techniques (if native is not available).

The problem with 6to4 is it was rolled out on a relatively large scale when 
there was essentially no IPv6 content. As a result, the people who had a
broken 6to4 setup would only find out when content providers would start
adding AAAA records. 

In other words, it was ticking time bomb.

This time bomb has been defused mostly because most operating system now prefer
any kind of IPv4 over a 6to4 address. So once again people can have a broken
6to4 setup without noticing it.

What worries me is that people will start using 6to4 for bittorrent. Bittorrent
will of course completely hide broken setups and worse, it will also hide 
broken 6to4 relays. 

So we may end up with a sizable group people who have an IPv6 setup that
completely doesn't work. And they don't know it.

Which will create all kinds of headaches for IPv6-only content because you
have to explain to users that yes, they have an IPv6 address and no, it is not
going to work.

And all of this, because a few hobbyists are afraid that declaring 6to4 as
historic will require them to search a bit harder in the furture for a
router that supports 6to4.

---

From: Keith Moore <[email-masked]>
Date: Sun, 3 Jul 2011 09:01:31 -0400

> large amount of e-mails.  For me, this is enough for "rough consensus".

There were several people opposing it at Last Call - enough that no amount of emails in favor would result in rough consensus.   What this is, is an attempt to railroad this through IETF without getting consensus.

> in a world without enough IPv4 addresses).

In the real world, there are lots of people successfully using 6to4, and there's no good replacement for it.

Keith

---

From: Keith Moore <[email-masked]>
Date: Sun, 3 Jul 2011 09:59:31 -0400

On Jul 3, 2011, at 3:23 AM, Randy Bush wrote:

> want to test ipv6 can manage to get it working.  big whoopie doo. 

I don't understand the desire to dismiss applications developers or existing 6to4 users as "a few geeks", but it's clearly a misrepresentation.

> it is a disaster for a significant percentage of the end users.  it needs to be stopped.

no, it needs to be fixed.  and many of the fixes have nothing to do with 6to4 implementations, but rather, with operators.

Keith

---

From: Keith Moore <[email-masked]>
Date: Sun, 3 Jul 2011 10:12:11 -0400

> should migrate to other tunneling techniques (if native is not available).

I think this clearly illustrates why IETF should issue a strong statement that

a) operators of 6to4 relays should not advertise those relays via BGP unless they're routing traffic for all of 2002://16 or native v6, respectively
b) operators should not filter protocol 41traffic
c) (maybe) operators using LSN should use RFC 1918 addresses behind those NATs unless/until there's another address range that 6to4 host implementations know about
d) 6to4 should be disabled by default in both hosts and routers
e) host implementations should prefer native v4 destinations over 6to4 destinations when both are available and the application can use either IPv4 or IPv6

Saying that no new 6to4 installation should be deployed and that existing 6to4 users should migrate to other tunneling techniques assumes that all installations and users have the same needs, namely, to access content over IPv6 that is also available over IPv4.

> In other words, it was ticking time bomb.

The label "broken 6to4 setup" is misleading.   Most of the time, the thing that breaks 6to4 is not the user's "setup"; it's an ISP somewhere that is either (a) advertising a bad relay or (b) filtering protocol 41.   (If the problem were the users' setups, the providers could just say "not our problem; fix your 6to4 setup")

> will of course completely hide broken setups and worse, it will also hide 

From my understanding of bittorrent, it will just find other routes.

> router that supports 6to4.

You completely misunderstand both the situation, and the size and diversity of 6to4 users.  

Keith

---

From: Cameron Byrne <[email-masked]>
Date: Sun, 3 Jul 2011 07:32:32 -0700

On Jul 3, 2011 7:14 AM, "Keith Moore" <[email-masked]> wrote:
> a) operators of 6to4 relays should not advertise those relays via BGP
unless they're routing traffic for all of 2002://16 or native v6,
respectively
> c) (maybe) operators using LSN should use RFC 1918 addresses behind those
NATs unless/until there's another address range that 6to4 host
implementations know about
> e) host implementations should prefer native v4 destinations over 6to4
destinations when both are available and the application can use either IPv4
or IPv6

You will not get "consensus" on these statements in the IETF or by the
various companies that implement gear and networks in the REAL world.

Can we let this thread die now? If the ietf will not kill 6to4, there are
several other methods to deal with it in the REAL world (dns whitelisting,
null routes, rfp's, blocking aaaa on ipv4 ....). Just like the NAT debacle
of years past , the IETF has once again proven its irrelevance.

Thanks for your time and have a great weekend.

Cb

> Saying that no new 6to4 installation should be deployed and that existing
6to4 users should migrate to other tunneling techniques assumes that all
installations and users have the same needs, namely, to access content over
IPv6 that is also available over IPv4.
> The label "broken 6to4 setup" is misleading.   Most of the time, the thing
that breaks 6to4 is not the user's "setup"; it's an ISP somewhere that is
either (a) advertising a bad relay or (b) filtering protocol 41.   (If the
problem were the users' setups, the providers could just say "not our
problem; fix your 6to4 setup")

---

From: Keith Moore <[email-masked]>
Date: Sun, 3 Jul 2011 10:40:53 -0400

On Jul 3, 2011, at 10:32 AM, Cameron Byrne wrote:
> You will not get "consensus" on these statements in the IETF or by the various companies that implement gear and networks in the REAL world.
> 
why not?  all of those recommendations are clearly appropriate and desirable, with the possible exception of (c) because ISP use of RFC 1918 addresses is likely to conflict with customer user of the same address ranges.
> Can we let this thread die now? If the ietf will not kill 6to4, there are several other methods to deal with it in the REAL world (dns whitelisting, null routes, rfp's, blocking aaaa on ipv4 ....). Just like the NAT debacle of years past , the IETF has once again proven its irrelevance.
> 

and the attitude from v6ops reminds me of nothing so much as a lynch mob.   it has gotten way out of hand. 

Keith

---

From: Arturo Servin <[email-masked]>
Date: Sun, 3 Jul 2011 11:58:36 -0300

And b.

	And probably it is too much effort for something that will go away (probably sooner that we expect) with the exhaustion of IPv4 addresses for each ISP's customer (6to4 does not work with NATs, and they are here).

-as

---

From: Keith Moore <[email-masked]>
Date: Sun, 3 Jul 2011 11:10:49 -0400

> 	And probably it is too much effort for something that will go away (probably sooner that we expect) with the exhaustion of IPv4 addresses for each ISP's customer (6to4 does not work with NATs, and…

It's clearly inappropriate for operators to be filtering protocol 41.   Not only does this break 6to4, it also breaks other tunneling mechanisms.  More generally, it's inappropriate for operators to be favoring one kind of traffic over another.

The ISPs I've talked to tell me that they see no reason why static, public IPv4 addresses cannot continue to be given to those that request them, indefinitely, as long as they're paying for business service. 

If the overriding concern is that imposition of LSN will break 6to4 even more and thus generate even more support calls,  that's understandable.  However:

- LSN will break a lot more than 6to4, and generate support calls for many other reasons, and this shouldn't surprise anyone.
- declaring 6to4 Historic will not reduce the number of support calls, while the above measures will.

The most effective single measure that I can see to reduce the number of 6to4 support calls is to get OS vendors to patch their customers' systems to implement (e), and perhaps (d), ASAP.   That shouldn't break 6to4 for anyone who is using it as a means of supporting IPv6 apps, and it should reduce the largest source of complaints both from users and content providers.  

(The reason I say "perhaps" (d) is that (d) would break those who are currently depending on 6to4.  "Off by default"  is perfectly appropriate for new installations, but not necessarily so for automatic updates.)

Keith

---

From: Tim Chown <[email-masked]>
Date: Sun, 3 Jul 2011 17:09:20 +0100

> in a world without enough IPv4 addresses).

I'm with Gert, Lorenzo, Randy and others here. 

It seemed that both the -advisory and -historic drafts had strong support in v6ops, which isn't just any WG, it's the WG that anyone with a vested interest in IPv6 deployment takes part.  Thus its view on IPv6 deployment practices should be given due regard.  The opposition on the IETF list seemed to be a vocal minority, and of course one person seemed to post a disproportionate number of replies.

The problems with 6to4 (20% minimum failure rate, and poor performance when it does connect) are well documented and have led to various 'counter measures' from the IETF, including:
a) 6to4 off by default, as per 6to4-advisory
b) IPv4 being preferred to 6to4 transport, as per 3484-bis (widely implemented already)
c) a fast fallback mechanism from IPv6 to IPv4, as per happy eyeballs (a simplistic version is already in Chrome)

Those measures indicate how bad a problem 6to4 creates.  If we're going to the trouble of coming up with all these measures, there seems to be a good case for 6to4 to Historic, which would be a steer to implementors to no longer include 6to4 support at all.  I do agree however that the most important point is publishing the -advisory text.

As a provider of a (not large) enterprise, I know that a fraction of 1% of connections to our site suffer a 10 second+ delay to a dual-stack web site where they suffer no delay to an IPv4-only one.  There's no way to know for sure how much of that 'IPv6 brokenness' is 6to4, but measures (a), (b), and (c) should minimise that figure.  Having said that, less than 1% of users who connect to our site over IPv6 use 6to4, so we wouldn't be aggrieved to see it disappear in terms of loss of users, as those users could almost certainly still reach us over IPv4.  Our own users who want IPv6 connectivity when offsite use tunnel brokers, which provide a much better (and more predictable) service, one that also works from behind a NAT, which in the reality of home, hotel, and other hotspot networks is quite important.
 
As for operators 'fixing' 6to4, well, I'd rather see operators invest that effort in deploying IPv6, rather than making 6to4 work better, for some value of 'better'.

Tim

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 3 Jul 2011 09:25:51 -0700

> and the attitude from v6ops reminds me of nothing so much as a lynch mob.   it has gotten way out of hand. 

You can let this thread die now.

you can stop ccing the IETF Discuss list, the IETF LC is over.

108 messages in two days in this thread has added precisely zero new viewpoints to the discussion, we know where all of you stand. 

If you live in the US enjoy the holiday, if you live in the northern hemisphere it's time  to go outside.

joel

---

From: Keith Moore <[email-masked]>
Date: Sun, 3 Jul 2011 14:13:00 -0400

On Jul 3, 2011, at 12:09 PM, Tim Chown wrote:

> It seemed that both the -advisory and -historic drafts had strong support in v6ops, which isn't just any WG, it's the WG that anyone with a vested interest in IPv6 deployment takes part.

That's simply false.   For instance, both users and applications developers are drastically underrepresented in that group.   

The interests of operators are certainly important and should be given due regard, but they are not the only interests that need to be considered.

>  Thus its view on IPv6 deployment practices should be given due regard.  The opposition on the IETF list seemed to be a vocal minority, and of course one person seemed to post a disproportionate number of replies.

One person's view should only be counted as one person's view, no matter how many messages he sends.     And yet, when even one person speaks up for the interests of an under-represented group, the merit of his arguments should be considered.

The reason we make decisions by consensus in IETF, rather than by voting, is that there's no way to have a representative sample of all interests.

And yes, a vocal minority can be sufficient to cause IETF to fail to reach consensus.  That's intentional.

> Those measures indicate how bad a problem 6to4 creates.

False.   The problems associated with 6to4 were not created by 6to4; they were created by dubious operational practices.  

But I note that all of the counter measures you cite are widely agreed on and well on their way to being reality.    Making 6to4 Historic in addition to these will not help; it will only hurt users who are successfully using it now.

>  If we're going to the trouble of coming up with all these measures, there seems to be a good case for 6to4 to Historic, which would be a steer to implementors to no longer include 6to4 support at all.

In other words, it's an attempt to sabotage 6to4 for those who are currently successfully using it, and without giving them a viable replacement.  It's an attempt to shift the pain from the operators to the users, for problems that were mostly caused by operators.

> As for operators 'fixing' 6to4, well, I'd rather see operators invest that effort in deploying IPv6, rather than making 6to4 work better, for some value of 'better'.

6to4 might need fixing, but it's not up to operators to fix it.    I think it's just fine if operators do things that they should normally be doing, i.e.: make a best effort to deliver all traffic (including protocol 41);  make sure that routers work properly; make sure that route advertisements are accurate.

Of course, if 6to4 could be replaced with something better, that would be a win for everyone.  For operators, I think that means deploying some form of v6 concurrently with LSN.   But I don't think the net can afford to trust that all operators will do this.

Keith

---

From: TJ <[email-masked]>
Date: Sun, 3 Jul 2011 14:53:15 -0400

On Sat, Jul 2, 2011 at 15:21, Cameron Byrne <[email-masked]> wrote:

> As a member of that "small but vocal minority" I think you are being a
little unfair here; some of us are working quite hard in getting IPv6
deployed in a number of different places.

> document as well. If so, we will have spent 3-6 months arguing about it for

And, FWIW, I have no objections to having it off by default.  In fact, I
welcome that.

/TJ

---

From: Arturo Servin <[email-masked]>
Date: Sun, 3 Jul 2011 16:17:37 -0300

> It's clearly inappropriate for operators to be filtering protocol 41.   Not only does this break 6to4, it also breaks other tunneling mechanisms.  More generally, it's inappropriate for operators t…

	Many corporate networks filter them because security concerns (I am not saying that is right or wrong, it just happens and it breaks 6to4). They won't change their mind because 6to4.

> The ISPs I've talked to tell me that they see no reason why static, public IPv4 addresses cannot continue to be given to those that request them, indefinitely, as long as they're paying for busines…

	Call one not in the USA. China or India perhaps.

-as

---

From: Keith Moore <[email-masked]>
Date: Sun, 3 Jul 2011 15:30:44 -0400

> 	Many corporate networks filter them because security concerns (I am not saying that is right or wrong, it just happens and it breaks 6to4). They won't change their mind because 6to4.

Fair enough.  (It bothers me when ISPs filter them, but I consider it within the rights of an enterprise network to do that.  What an enterprise does with its own traffic should be its own business, and they can benefit and/or suffer from the consequences of their choices.  Though I do think that there are probably better ways to handle the (legitimate) security concerns than to merely filter protocol 41.  e.g. ICMP unreachable.)

And of course protocol 41 becomes problematic for those behind a NAT of any kind, including LSN.    (I do see LSN as "best effort" delivery; it's just that the state of the the network has made "best" pretty sad these days.)

So if we were able to omit or finesse considerations (b) and (c) could we get consensus around the remaining items in that list?

> 	Call one not in the USA. China or India perhaps.

I'll take your word for it.   6to4 is only going to work in corner cases, and those corners are somewhat defined by geography.

Honestly I'd be happy to declare 6to4 Historic if we had a suitable replacement - one that could be automatically configured by hosts, used by applications, and worked better than 6to4 in most cases.  I don't think it exists yet.  

(That oft-touted 80% reliability figure needs to be compared with similar figures for other methods, along with the realization that manual configuration, lack of platform support,  congestion at heavily-used tunnel endpoints, are all significant sources of failure.  Note that you can't measure this by looking only at traffic in the network.   And for those who insist that all v6 traffic should be native, note that from the perspective of an application developer, there is close to a 0% reliability for this at present.  80% is a huge improvement over that, though still not good enough.)

Keith

---

From: Roger Jørgensen <[email-masked]>
Date: Sun, 3 Jul 2011 21:32:45 +0200

A bit late since this threat will be moderated soon. But I strongly object
to this delay of needed action.

I guess the other way the problem, which will hurt muchmuch more is maybe to
considering a filter of 6to4 on isp level?
I will suggest it when we start deploying native ipv6.

--- Roger J. ---
> Whereas there has been considerable controversy regarding
draft-ietf-v6ops-6to4-to-historic, the v6ops chairs and document author have
> - The author will introduce a new draft, intended for standards track
publication. The new draft will update RFCs 3056 and 3068. It will say that
if 6-to-4 is implemented, it must be turned off by default.
WG and IETF consensus

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 03 Jul 2011 21:35:19 +0100

On 03/07/2011 14:59, Keith Moore wrote:
> no, it needs to be fixed.

There is no fix.  The protocol has no dead broker detection and this cannot
be changed without rewriting the protocol from scratch.   In the absence of
dead broker detection, the only option as an end-user is to hope that
things work, and if your connectivity is trashed, to depend on the
benevolence of third parties with whom you have no recourse.

Speaking as an operator, I do not understand how supporting the continued
existence of a protocol of this level of brokenness constitutes good
stewardship.

>From an operational point of view, the only viable option is to remove the
protocol from the Internet, and this document is the first step in that
direction.

Nick

---

From: Mark Andrews <[email-masked]>
Date: Mon, 04 Jul 2011 10:54:38 +1000

In message <EMEW3|9c8bf9e7fa0e59322f84c8ec6df2b8b9n62HAg03tjc|ecs.soton.ac.uk|0
[email-masked]>, Tim Chown writes:
> It seemed that both the -advisory and -historic drafts had strong support in 
> v6ops, which isn't just any WG, it's the WG that anyone with a vested interes
> t in IPv6 deployment takes part.  Thus its view on IPv6 deployment practices 
> should be given due regard.  The opposition on the IETF list seemed to be a v
> ocal minority, and of course one person seemed to post a disproportionate num
> ber of replies.
> 
> The problems with 6to4 (20% minimum failure rate, and poor performance when i
> t does connect) are well documented and have led to various 'counter measures
> ' from the IETF, including:

No.  The 20% connect failure rate shows how bad AUTOMATIC 6to4 is.
It show NOTHING about how bad 6to4 itself is.  As for longer RTT
that is something people accept as part of using 6to4.  I know I
accept that they are there for the trans Pacific tunnel I use.

As for high failure rates.  EDNS (RFC 2671) had/has a similar or
higher failure rates with any UDP packets that are bigger that 512
bytes or UDP packets that get fragmented or packets that have a OPT
record in the additional section or have DO (RFC 3225) set in the
OPT record.  Firewalls are a pain in the proverbial but we don't
stop attempting to use EDNS because they are there.  Nameservers
tailor their queries to to work around firewalls (happy eyeballs)
and log that they needed to use the workarounds.

>  If we're going to th
> e trouble of coming up with all these measures, there seems to be a good case
>  for 6to4 to Historic, which would be a steer to implementors to no longer in
> clude 6to4 support at all.  I do agree however that the most important point 
> is publishing the -advisory text.

As for the counter measures, some of them need to be there independently
of 6to4.  Google Chome was the only brower that could reach
www.ietf.org in a timely manner from any dual stack client connecting
via Hurricane Electric for half of last week.  The noc @HE responded
to the issue within 1/2 a hour of it being raised via email by
raising a trouble ticket with AT&T.  It still took 2-3 days for the
problem to be fixed.

> As a provider of a (not large) enterprise, I know that a fraction of 1% of co
> nnections to our site suffer a 10 second+ delay to a dual-stack web site wher
> e they suffer no delay to an IPv4-only one.

Which for the most part wouldn't be there if 6to4 required explicit
configuration.

> There's no way to know for sure 
> how much of that 'IPv6 brokenness' is 6to4, but measures (a), (b), and (c) sh
> ould minimise that figure.  Having said that, less than 1% of users who conne
> ct to our site over IPv6 use 6to4, so we wouldn't be aggrieved to see it disa
> ppear in terms of loss of users, as those users could almost certainly still 
> reach us over IPv4.  Our own users who want IPv6 connectivity when offsite us
> e tunnel brokers, which provide a much better (and more predictable) service,
>  one that also works from behind a NAT, which in the reality of home, hotel, 
> and other hotspot networks is quite important.
>
> As for operators 'fixing' 6to4, well, I'd rather see operators invest that ef
> fort in deploying IPv6, rather than making 6to4 work better, for some value o
> f 'better'.

The fixes for 6to4 are deploying suitable sized 6to4 relay boxes
and removing protocol 41 filters once the isp has some IPv6
connectivity.  The time and effort required to do this is minimal
compared to the time and effort required to deploy IPv6 to all of
its customers.

Remember you don't need to bill for this as the billing is already
taken care of with IPv4.  You don't need to do address assignments
as they are taken care of with IPv4.

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

---

From: Frank Habicht <[email-masked]>
Date: Mon, 04 Jul 2011 08:52:31 +0300

> in a world without enough IPv4 addresses).

+1 Frank Habicht, Operator.

---

From: james woodyatt <[email-masked]>
Date: Tue, 05 Jul 2011 12:47:57 -0700

[distribution narrowed]

> If anyone objects to this course of action, please speak up soon.

Assuming the details are specified clearly to set the standard that seems to be the IETF consensus, which is to make this default configuration REQUIRED, i.e. what I-D.ietf-v6ops-6to4-advisory currently only recommends in all lower-case letters, then I can see how this will be a useful document for IETF to publish and I can support its development.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 5 Jul 2011 13:39:26 -0700

I shudder to think that this is a prerequisite for declaring something Historic.

If some RFC meant to solve some problem turns out not only to be a bad idea but also shows that the problem itself is essentially intractable, I don't think it's practical at all to require a replacement before declaring the RFC Historic.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Keith Moore
Sent: Sunday, July 03, 2011 12:31 PM
To: Arturo Servin
Cc: IPv6 Operations; IETF Discussion
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic

[...]

Keith

---

From: Martin Rex <[email-masked]>
Date: Wed, 6 Jul 2011 02:54:29 +0200 (MEST)

Gert Doering wrote:
> There's two very vocal persons opposing it

There were more than two clearly opposing, and there is no need to
further fuel the heated discussion by everyone becoming as vocal
as Keith.   The pain point is really the unnecessarily aggressive
"kill what we don't like" move-to-historic action.

This is a procedural issue, not a matter of personal taste.
There was an alternative reclassification suggested, that
could gather rough consensus.

I'm still waiting for a *clean* resolution of the procedural issue
(that means serious consideration of suggested alternatives).

-Martin

---

From: Randy Bush <[email-masked]>
Date: Wed, 06 Jul 2011 10:39:07 +0900

> The pain point is really the unnecessarily aggressive "kill what we
> don't like" move-to-historic action.

if we killed everything i do not like, there would be lot fewer rfcs. :)

what people are saying is kill it because it is broken, bad, and does a
dis-service to ipv6.

randy

---

From: james woodyatt <[email-masked]>
Date: Wed, 06 Jul 2011 09:45:24 -0700

On Jul 5, 2011, at 6:39 PM, Randy Bush wrote:
> 
> what people are saying is kill it because it is broken, bad, and does a dis-service to ipv6.

Actually, I seem to have been the only person who proposed killing it-- the rest of you seem to have settled on merely looking at it crossly and hoping it will wither away in shame.

By that I mean, I wrote up and circulated an Internet Draft to specify a phase-out plan for RFC 3056 and RFC 3068.  I chose not to submit it when it was made clear to me that no such plan could be adopted as a working group item.

On a related note, I much prefer Keith Moore's proposal to reclassify RFC 3056 and RFC 3068 as Experimental.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 06 Jul 2011 20:29:58 +0200

In your letter dated Wed, 06 Jul 2011 09:45:24 -0700 you wrote:
>Actually, I seem to have been the only person who proposed killing it-- the re
>st of you seem to have settled on merely looking at it crossly and hoping it w
>ill wither away in shame.

I'd say that the main attack on 6to4 has already happened: most operating
systems now prefer IPv4 over IPv6 when the host has a 6to4 address.

> and RFC 3068 as Experimental.

In that light, maybe it is good idea to direct hosts to ignore 6to4 prefixes
for the purpose of SLAAC (unless explictly configured to accept them) and also
to assign the priority low to any default router that also announces a 6to4
prefixes for SLAAC.

That should get rid of almost all accidental use of 6to4 while still allowing
expert users to use it. 

(I'm considering switching to 6to4 to get something unreliable enough to
actually test happy eyeballs :-)

---

From: Keith Moore <[email-masked]>
Date: Wed, 6 Jul 2011 14:43:32 -0400

> to assign the priority low to any default router that also announces a 6to4

No, that makes no sense.  The host has no way of knowing whether the 6to4 prefix is being advertised because the network was deliberately configured to use it, or because the router enabled it by default.  And relatively few routers ever did that.

Make 6to4 off by default at the router, and make host 6to4 off by default, but don't have hosts second-guess SLAAC.

Keith

---

From: james woodyatt <[email-masked]>
Date: Wed, 06 Jul 2011 11:46:25 -0700

On Jul 6, 2011, at 11:29 , Philip Homburg wrote:
> for the purpose of SLAAC...

That's what I expect will have to be done if I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel isn't stopped.

---

From: Keith Moore <[email-masked]>
Date: Wed, 6 Jul 2011 15:11:17 -0400

> That's what I expect will have to be done if I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel isn't stopped.

6to4-provider-managed-tunnel should absolutely be stopped.  Anything that does prefix translation in IPv6 is a very dubious idea. 

Keith

---

From: Doug Barton <[email-masked]>
Date: Wed, 06 Jul 2011 13:08:11 -0700

> Actually, I seem to have been the only person who proposed killing it-- the rest of you seem to have settled on merely looking at it crossly and hoping it will wither away in shame.

... as well it should. :)

Meanwhile I have stated several times that I'd like it to be gone, 
completely, yesterday. I was however willing to accept "historic" as a 
reasonable compromise.

Doug

--

---

From: Martin Rex <[email-masked]>
Date: Wed, 6 Jul 2011 22:14:38 +0200 (MEST)

> completely, yesterday. I was however willing to accept "historic" as a 

"historic" as a compromise?  Between which two positions?
 
-Martin

---

From: Doug Barton <[email-masked]>
Date: Wed, 06 Jul 2011 13:18:38 -0700

> "historic" as a compromise?  Between which two positions?

Nuking it from orbit, and erecting a statue in its honor?

:)

Doug

--

---

From: Martin Rex <[email-masked]>
Date: Wed, 6 Jul 2011 22:49:47 +0200 (MEST)

Doug Barton wrote:
> > > I was however willing to accept "historic" as a reasonable compromise.
> >

Which to options that are actually available to the IESG?  I see

extremist-A:  nuke/kill 6to4 by moving 3056/3068 to historic

compromise:   move 3056/3068 off Standards Track,
              i.e. by reclassifying them as Experimental

blocked:      leave 3056/3068 at Proposed, publish only 6to4-advisory

extremist-B:  stick fingers in ears, sing la-la-la, pretend 6to4 is perfect

-Martin

---

From: Yoav Nir <[email-masked]>
Date: Thu, 7 Jul 2011 11:30:06 +0300

Extremist-A should be to publish a "6to4 considered dangerous" draft with lots of MUST NOT language.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Rex
Sent: 06 July 2011 23:50
To: Doug Barton
Cc: [email-masked]; [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic

-Martin

Scanned by Check Point Total Security Gateway.

---

From: Doug Barton <[email-masked]>
Date: Thu, 07 Jul 2011 09:25:03 -0700

... or to use Randy's language, "6to4 considered caterpillar snot," but
yes, that is what I was thinking that end of the spectrum looked like.

Doug

--

---

From: Roger Jørgensen <[email-masked]>
Date: Fri, 8 Jul 2011 09:16:24 +0200

Guess I should clearify something, the thing I am considering are to
drop all 2002::/16 addresses hard, of course preferable return a
correct error messages to.

wonder how many find 6to4 usable when ISPs start doing that? Nuclear
winter or not may follow.

--- Roger J ---

-- 

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

---

From: Ole Troan <[email-masked]>
Date: Fri, 8 Jul 2011 11:00:22 +0200

Roger,

> winter or not may follow.

took me a while to warm up to PMT, but now I think that's a perfectly valid solution to rescue the set of innocent victims of 6to4.
http://tools.ietf.org/html/draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-02

wouldn't be surprised if there already are commercial products that can do that.

cheers,
Ole

---

From: Tim Chown <[email-masked]>
Date: Fri, 8 Jul 2011 11:11:21 +0100

> That's what I expect will have to be done if I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel isn't stopped.

I recall that a hum to adopt the pmt draft as a WG item in Prague failed.

Tim

---

From: Keith Moore <[email-masked]>
Date: Fri, 8 Jul 2011 09:02:58 -0400

> winter or not may follow.

seems like that just exacerbates the problem for your own customers and for other operators.

Keith

---

From: Erik Kline <[email-masked]>
Date: Sat, 9 Jul 2011 00:06:31 +0900

On 8 July 2011 19:11, Tim Chown <[email-masked]> wrote> On 6 Jul
> I recall that a hum to adopt the pmt draft as a WG item in Prague failed.

Ditto.  My own personal feeling is that if someone really wants to do
this, so be it, but I see absolutely no reason why it should be
standardized or have any more nod of approval from the IETF than an
individual submission.

---

From: Keith Moore <[email-masked]>
Date: Fri, 8 Jul 2011 12:43:33 -0400

> standardized or have any more nod of approval from the IETF than an

I have serious problems with the notion that ISPs should deliberately break 6to4 (which is what this draft proposes to do, though in a subtle and I presume unintentional way).

One of the primary justifications for developing new applications that use IPv6, is the ability to run those applications without having to deal with NAT.    Depending on the application, dealing with NAT in IPv4 can require a huge investment in infrastructure - and this currently serves as a barrier to deployment of new applications in IPv4.    NATting IPv6 makes IPv6 just as dysfunctional as IPv4.     (And yeah, I know some enterprise networks are going to do it anyway, but hopefully they'll soon realize that they're only hurting themselves.)

Honestly, I'd rather see ISPs set up relay routers that returned ICMP network unreachable packets, than for them to apply this "fix".   (Of course, such relay routers should only be advertised to that ISP's own customers.)

Keith

---

From: Ole Troan <[email-masked]>
Date: Fri, 8 Jul 2011 19:33:01 +0200

Keith,

> Honestly, I'd rather see ISPs set up relay routers that returned ICMP network unreachable packets, than for them to apply this "fix".   (Of course, such relay routers should only be advertised to t…

assuming that it is true (and I'm speculating) that most users running 6to4 are unaware of it (consequence of default on in devices).
then the pragmatic response by their ISP to help these users, would be to PMT then. I believe the PMT draft allows for willing users to bypass the prefix translation.

I'm all for it, if we can't get rid of 6to4, then PMT it away from the global Internet.

introducing a relay router doesn't fix the return path.

cheers,
Ole

---

From: Keith Moore <[email-masked]>
Date: Fri, 8 Jul 2011 14:18:59 -0400

> then the pragmatic response by their ISP to help these users, would be to PMT then. I believe the PMT draft allows for willing users to bypass the prefix translation.

It's simply not acceptable for operators to NAT IPv6.   

> introducing a relay router doesn't fix the return path.

No, but a "relay router" that returned ICMP network unreachables would (a) give applications a chance to realize that the address that they chose did not work, and allow them to fail over to a different address if one were available, and (b) provide a quick indication of failure to the host (and hopefully the application) rather than waiting for a TCP connection timeout.

(I actually think there are other ways to fix the return path problem, but they need more work.)

Keith

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 8 Jul 2011 14:56:05 -0400

Chairs,

What is the status of this email thread? At least one participant thinks that it has been ended or paused. Others think that it is still active.

Are the floodgates open or closed?

Also, it might be good to put time on the agenda in Quebec for this topic.

                                         Ron
                                         <speaking as individual contributor>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 09 Jul 2011 11:35:30 +1200

> correct error messages to.

This is an awesomely bad idea. As explained in the approved advisory
document, it makes things worse for everybody (the user, the content
provider, and the unfortunate person answering calls from either of
them at the help desk).

On the contrary - it's in everyone's interests to have the return
path working. Once a user manages to get a packet to the content
provider, everybody suffers if the return path fails.

(However, if you are announcing a route to 2002::/16, it must lead
to a relay that will relay all 6to4 packets, with no form of ACL).

   Brian

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 8 Jul 2011 16:47:58 -0700

I, for one, am not interested talking about 6to4 anymore.
On Jul 8, 2011 4:36 PM, "Brian E Carpenter" <[email-masked]>

---

From: Victor Kuarsingh <[email-masked]>
Date: Fri, 08 Jul 2011 20:19:52 -0400

Ole

On 11-07-08 1:33 PM, "Ole Troan" <[email-masked]> wrote:

>> I have serious problems with the notion that ISPs should deliberately
>>break 6to4 (which is what this draft proposes to do, though in a subtle
>>and I presume unintentional way).
>> 
>> One of the primary justifications for developing new applications that
>>use IPv6, is the ability to run those applications without having to
>>deal with NAT.    Depending on the application, dealing with NAT in IPv4
>>can require a huge investment in infrastructure - and this currently
>>serves as a barrier to deployment of new applications in IPv4.
>>NATting IPv6 makes IPv6 just as dysfunctional as IPv4.     (And yeah, I
>>know some enterprise networks are going to do it anyway, but hopefully
>>they'll soon realize that they're only hurting themselves.)
>> 
>> Honestly, I'd rather see ISPs set up relay routers that returned ICMP
>>network unreachable packets, than for them to apply this "fix".   (Of
>>course, such relay routers should only be advertised to that ISP's own
>>customers.)
>
>assuming that it is true (and I'm speculating) that most users running
>6to4 are unaware of it (consequence of default on in devices).
>then the pragmatic response by their ISP to help these users, would be to
>PMT then. I believe the PMT draft allows for willing users to bypass the
>prefix translation.

Yes, you can by-pass if you are are an "aware" 6to4 user. Have fun with
the global system. 

>I'm all for it, if we can't get rid of 6to4, then PMT it away from the

Our experience from WIPv6 (also before and after) was that PMT worked
well.  We have users in both camps, some were PMTed and others were not.
Both can work in parallel.  Default deployments (Policy is b Subnet-ID)
using subnet-ID 0 were translated and appeared with native IPv6 address to
the Internet (I.e. When going to some content).

>From a performance perspective, similar as 6RD based on our tests.

Most users did not notice other then much improved RTTs and removal of
dependancy on remote relays.

>introducing a relay router doesn't fix the return path.

Correct.  There are some improvements as we saw in our network, and others
like Comcast saw in their network (per
draft-jjmb-v6ops-comcast-ipv6-experiences-01).

---

From: Keith Moore <[email-masked]>
Date: Fri, 8 Jul 2011 20:28:56 -0400

On Jul 8, 2011, at 8:19 PM, Victor Kuarsingh wrote:

> well.  

A lot of people think IPv4 NAT works well too.  Then when an application doesn't work, they blame the application.  Or when an application fails to succeed because the IPv4 network is dysfunctional, and there's not a big enough market to support the infrastructure required to work well thorough NAT, users never realize that they lost the ability to run something useful because of NAT.

NAT is completely unacceptable for IPv6.

Keith

---

From: "Lee, Yiu" <[email-masked]>
Date: Sat, 9 Jul 2011 00:35:53 +0000

I don't think Victor implies he promotes NAT for IPv6. I believe he is
very much promoting native IPv6. All he said was trying to improve the RTT
for 6to4 users. He also provides a way to opt-out if NAT is a concern.

On 7/8/11 8:28 PM, "Keith Moore" <[email-masked]> wrote:

>A lot of people think IPv4 NAT works well too.  Then when an application
>doesn't work, they blame the application.  Or when an application fails
>to succeed because the IPv4 network is dysfunctional, and there's not a
>big enough market to support the infrastructure required to work well
>thorough NAT, users never realize that they lost the ability to run
>something useful because of NAT.
>

---

From: Keith Moore <[email-masked]>
Date: Fri, 8 Jul 2011 20:49:28 -0400

It's still imposing NAT by default.  That's a lot worse than, say, using 6to4 by default in preference to IPv4.

I believe there's widespread agreement on a number of measures which should reduce accidental/casual use of 6to4.  As for the return-path problem for the remaining users of 6to4, there are better ways to improve that situation than with NAT.

Keith

---

From: Victor Kuarsingh <[email-masked]>
Date: Fri, 08 Jul 2011 21:38:13 -0400

Keith,

>6to4 by default in preference to IPv4.

Agreed.  NAT is less then desirable.  Although the imposition of NAT is to
deal with a problematic connection where the default behaviour may cause
problems.  So the choice being made is not NAT vs. Good IPv6, but NAT vs.
Problematic IPv6.

The goal is to make the user experience better.  Users (the average user)
tend to look for the cosmetics in the Internet experience.  "I" click on
some content, it shows up on "my" screen - I am happy (the ugly mechanics
of the connection doesn't seem to keep them up at night).

I am not suggesting for moment that 6to4 with PMT will make all things
beautiful.  It's to fix/manage a challenge during this period of initial
transition (as content states to become available on IPv6 but native
deployments lag).  This is temporary until Native is deployed (as I assume
we all agree that 6to4 - even if all major Operators had relays etc - is
not the strategic answer for IPv6 deployments).

>
>I believe there's widespread agreement on a number of measures which
>should reduce accidental/casual use of 6to4.  As for the return-path
>problem for the remaining users of 6to4, there are better ways to improve
>that situation than with NAT.

Sure, and if the measures make it out to the deployed hosts/hardware then
great.  My concern is we are talking about it; and by the time the group
decides on how best to guide the protocol; vendors/developers implement
it; and it's pushed out - it may be too late.

6to4 is a problem now not later.  If these measures are implemented later,
then back to normal 6to4 we go.

Victor K

---

From: Keith Moore <[email-masked]>
Date: Fri, 8 Jul 2011 22:02:21 -0400

> problems.  So the choice being made is not NAT vs. Good IPv6, but NAT vs.

No, that's a mischaracterization.   In many cases the IPv6 service provided by 6to4 is good.   And it's not the case that 6to4 with PMT is better than bad 6to4.   Even in those cases, PMT just replaces one kind of brokenness with another, and the brokenness imposed by PMT is even more subtle and harder to diagnose.  Again, it would be far better to impose a relay router that always returned ICMP network unreachable messages than to impose PMT.

> of the connection doesn't seem to keep them up at night).

It's a mistake to judge 6to4 by how well it works with HTTP.   It's also a mistake to use 6to4 (or any other v6-over-v4 tunnel) in preference to IPv4 for HTTP (or any other common client-server protocol that works fine through NAT).  6to4 and other v6-over-v4 tunneling technologies should be used for apps that need v6.  The default behavior for hosts should be to prefer native v6 > native v4 > tunneled v6 over v4.   There's no disagreement about that, and the default is being fixed.   Once the default is fixed, it's a good bet that any application that explicitly chooses to use IPv6 actually wants IPv6, and there's a good chance that the reason that the app wants v6 is to avoid NAT.

> not the strategic answer for IPv6 deployments).

It's not acceptable to harm applications that use 6to4 just because native v6 isn't here yet.  You might not believe that PMT will harm 6to4, but it will.

> then back to normal 6to4 we go.

6to4 is not a problem; rather, poor operational practices are causing problems with 6to4.  You're proposing yet another poor operational practice.

And fixes for at least some of the problems associated with 6to4 are already in the pipeline.   Implementations will be updated to disable 6to4 by default, and to choose v4 in preference to 6to4. 

Keith

---

From: Turchanyi Geza <[email-masked]>
Date: Sat, 9 Jul 2011 09:12:37 +0200

Brian's comments were usefull, I think.

Best,

Géza