Subject: [v6ops] Last Call: <draft-ietf-v6ops-6to4-to-historic-04.txt> (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC

From: The IESG <[email-masked]>
Date: Mon, 06 Jun 2011 09:23:26 -0700

The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to
   Historic status'
  <draft-ietf-v6ops-6to4-to-historic-04.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2011-06-20. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   Experience with the "Connection of IPv6 Domains via IPv4 Clouds
   (6to4)" IPv6 transitioning mechanism has shown that the mechanism is
   unsuitable for widespread deployment and use in the Internet.  This
   document requests that RFC3056 and the companion document "An Anycast
   Prefix for 6to4 Relay Routers" RFC3068 are moved to historic status.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/

No IPR declarations have been submitted directly on this I-D.

---

From: Keith Moore <[email-masked]>
Date: Mon, 6 Jun 2011 13:22:27 -0400

I strongly object to the proposed reclassification of these documents as Historic.  

6to4 still has many valid use cases, and there is not a suitable replacement for it that has been deployed.  Until there is a suitable replacement, or until there is widespread ISP support for native IPv6, reclassification of this document to Historic is premature.  (6rd is not a suitable replacement for 6to4, as it is intended for very different use cases than 6to4.)

(It could be argued that reclassification of RFC 3068 (by itself) to Historic is appropriate, but that would require a separate document and last call.)

In addition, this document is misleading and perhaps even vituperative.    For instance:

"There would appear to be no evidence of any substantial deployment of the variant of 6to4 described in [RFC3056]."

This statement is blatantly false. 6to4 is supported by every major desktop and server platfrom that is shipping today, and has been supported for several years.

"The IETF sees no evolutionary future for the mechanism and it is not recommended to include this mechanism in new implementations."

6to4 never was intended to have an "evolutionary future".  It was always intended as a near-term solution to allow consenting hosts and networks to interchange IPv6 traffic without prior support from the IPv4 networks that carry the traffic.   It is premature to recommend that 6to4 be removed from implementations.  We do not know how long it will take ISPs to universally deploy IPv6.  Until they do, there will be a need for individuals and enterprises using IPv6-based applications to be able to exchange IPv6 traffic with hosts that only have IPv4 connectivity.  

All of the criticisms in section 3 have to do with the use of relays to exchange traffic between 6to4 and native IPv6.   In many cases the criticisms are overbroad.   Not all uses of 6to4 involve relays.  For some of those that do need to use relays, it is not necessarily the case that the relay is operated by an unknown third-party.  

The fact that some firewalls block protocol 41 traffic causes problems for many tunneling solutions, not just 6to4; yet this document appears to recommend some tunneling solutions while trashing 6to4.

The recommendations to treat 6to4 as a service of last resort will do harm to users and applications using it.   A better recommendation is for hosts to disable 6to4 by default.  

This document appears to make the mistake of assuming that the purpose of applications using IPv6 is to interoperate with the existing Internet.  I have maintained for many years that it is new applications, or existing applications that can't tolerate widespread deployment of IPv4 NAT, that will drive use of IPv6.   I therefore believe that it is inappropriate to judge 6to4 merely by how well it works in scenarios where it is being used to talk to applications that work well over IPv4 NAT such as HTTP.   The Internet is much more diverse than that, and will become even more diverse as IPv6 enjoys wider deployment.

It is also premature to remove references to 6to4 from RFC 5156bis, for IANA to mark the prefix and DNS zones as deprecated.  This will only cause confusion and difficulty for legitimate continued uses of 6to4.

Keith

On Jun 6, 2011, at 12:23 PM, The IESG wrote:

> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: "George, Wesley" <[email-masked]>
Date: Mon, 6 Jun 2011 13:35:42 -0400

Did I miss the discussion where we decided to make this informational instead of proposed standard? What was the rationale?

Thanks,

Wes George

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of The IESG
Sent: Monday, June 06, 2011 12:23 PM
To: IETF-Announce
Cc: [email-masked]
Subject: [v6ops] Last Call: <draft-ietf-v6ops-6to4-to-historic-04.txt> (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC

Abstract

_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 6 Jun 2011 14:49:18 -0400

Hi Wes,

The reason was that it could achieve its goal as INFORMATIONAL. Specifically, the mechanism for obsoleting a document and changing its status to HISTORIC is to write another RFC. However, that new RFC does need to have the same status as the document that it obsoletes. An INFORMATIONAL RFC is sufficient to obsolete a PS RFC.

                                                 Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of George, Wesley
Sent: Monday, June 06, 2011 1:36 PM
To: [email-masked]
Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-6to4-to-historic-04.txt> (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC

Thanks,

Wes George

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of The IESG
Sent: Monday, June 06, 2011 12:23 PM
To: IETF-Announce
Cc: [email-masked]
Subject: [v6ops] Last Call: <draft-ietf-v6ops-6to4-to-historic-04.txt> (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC

Abstract

---

From: Fred Baker <[email-masked]>
Date: Mon, 6 Jun 2011 11:51:52 -0700

> Did I miss the discussion where we decided to make this informational instead of proposed standard? What was the rationale?

Requested by the AD. The argument for standards track was that it addressed a standards track document. The IESG apparently opines that an informational document will do the job and is their preference.

---

From: TJ <[email-masked]>
Date: Mon, 6 Jun 2011 19:41:49 -0400

On Mon, Jun 6, 2011 at 13:22, Keith Moore <[email-masked]>wrote:

> *<snipped lots of great thoughts/comments, solely for brevity>*
>

Agreed that this is too harsh, too soon.  Fixing the broken implementations
is a better idea than trying to break the working ones.  And I am not just
saying this because I successfully use 6to4 on a fairly common basis ...

/TJ

---

From: Gert Doering <[email-masked]>
Date: Tue, 7 Jun 2011 08:33:36 +0200

Hi,

> saying this because I successfully use 6to4 on a fairly common basis ...

Do we really need to go through all this again?

As long as there is no Internet Overlord that can command people to 
a) put up relays everywhere and b) ensure that these relays are working,
6to4 as a general mechanism for attachment to the IPv6 Internet is FAIL.

If someone wants to use 6to4 to interconnect his machines over an IPv4
infrastructure (=6to4 on both ends), nobody is taking this away.

Gert Doering
        -- NetMaster
-- 
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: Tim Chown <[email-masked]>
Date: Tue, 7 Jun 2011 08:13:14 +0100

> infrastructure (=6to4 on both ends), nobody is taking this away.

Exactly.

Less than 1% of the IPv6 traffic reaching us is 6to4. And 6to4 in its 6to4-to-native mode is proven to be highly unreliable. It seems highly preferable to have that 1% wait for native IPv6 to be available to them, rather than being used as a reason by the bigger content providers for holding back production deployment, which is what we all want to see.

It's time to remove the stabilisers on the IPv6 bicycle.

Tim

---

From: Ole Troan <[email-masked]>
Date: Tue, 7 Jun 2011 10:48:41 +0200

Keith,

I'm loathe to go through this discussion again. let me just respond to some of the points you make, and then agree that we disagree.

> This statement is blatantly false. 6to4 is supported by every major desktop and server platfrom that is shipping today, and has been supported for several years.

incorrect. there is no evidence that the  _managed_ model of 6to4 described in rfc3056 has any deployment.
that's the model where relay operators advertise what parts of the 6to4 space they are routing. with BGP neighborships between managed and participating relays.

_deployment_ not _support_.

> The fact that some firewalls block protocol 41 traffic causes problems for many tunneling solutions, not just 6to4; yet this document appears to recommend some tunneling solutions while trashing 6t…

it is the unmanaged aspect of 6to4 deployment that exhibits the most problems. a manually configured managed point to point tunnel may also be blocked in a firewall, but then the operator will have to sort that out. 6to4 has no operator.
Teredo is similar in many aspects to 6to4, but there is little evidence that it causes the same problems. largely because it is the choice of last resort in implementations and it hasn't/can't be enabled by default in CPEs.

> This document appears to make the mistake of assuming that the purpose of applications using IPv6 is to interoperate with the existing Internet.  I have maintained for many years that it is new app…

6to4 does not work through IPv4 NATs.

> It is also premature to remove references to 6to4 from RFC 5156bis, for IANA to mark the prefix and DNS zones as deprecated.  This will only cause confusion and difficulty for legitimate continued…

the purpose of the text in the document is to ensure that the deprecated prefixes are not reused before 6to4 has been phased out.

cheers,
Ole

---

From: TJ <[email-masked]>
Date: Tue, 7 Jun 2011 07:33:28 -0400

> Less than 1% of the IPv6 traffic reaching us is 6to4.

Unless you provide IPv6 only sites, you should see very little ... that is
part of the point :).

<snip>

> It's time to remove the stabilisers on the IPv6 bicycle.

I agree, but get me native everywhere before taking away one connection
mechanism that does work.

Just my $.02,
/TJ ... ready for world IPv6 Day?

---

From: "George, Wesley" <[email-masked]>
Date: Tue, 7 Jun 2011 08:56:27 -0400

From: [email-masked] [mailto:[email-masked]] On Behalf Of TJ
Sent: Tuesday, June 07, 2011 7:33 AM
To: Tim Chown
Cc: [email-masked] WG; [email-masked]
Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-6to4-to-historic-04.txt> (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC

> It's time to remove the stabilisers on the IPv6 bicycle.
I agree, but get me native everywhere before taking away one connection mechanism that does work.

This takes nothing away. It's not as if the day that this draft gets published as an RFC, 6to4 stops working. IETF has moved other protocols to historical status before they were out of heavy use, with the expectation that it would take some time for the alternatives to be deployed and existing implementations to be retired. This is specifically why we resisted the idea of putting in a shutdown schedule or other flag day where the 6to4 prefixes get null-routed, because it's likely to be different in each network and application.

"In order to limit the impact of end-users, it is
   recommended that operators retain their existing 6to4 relay routers
   and follow the recommendations found in
   [I-D.ietf-v6ops-6to4-advisory].  When traffic levels diminish, these
   routers can be decommissioned."

Wes George

---

From: TJ <[email-masked]>
Date: Tue, 7 Jun 2011 09:34:59 -0400

On Tue, Jun 7, 2011 at 08:56, George, Wesley <[email-masked]>wrote:

> Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-6to4-to-historic-04.txt>
> (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to
> Historic status) to Informational RFC
>
> This takes nothing away. It's not as if the day that this draft gets
> published as an RFC, 6to4 stops working. IETF has moved other protocols to
> historical status before they were out of heavy use, with the expectation
> that it would take some time for the alternatives to be deployed and
> existing implementations to be retired. This is specifically why we resisted
> the idea of putting in a shutdown schedule or other flag day where the 6to4
> prefixes get null-routed, because it's likely to be different in each
> network and application.
>
I agree with the end goal here, but for a mechanism that relies on the good
will of others (relays) changing it to "historic" could have a more-abrupt
impact on those who use the mechanism than in other cases of similar
demotions.  That is my concern.

 /TJ

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 7 Jun 2011 06:58:34 -0700

On Jun 7, 2011 12:16 AM, "Tim Chown" <[email-masked]> wrote:
> Less than 1% of the IPv6 traffic reaching us is 6to4. And 6to4 in its
6to4-to-native mode is proven to be highly unreliable. It seems highly
preferable to have that 1% wait for native IPv6 to be available to them,
rather than being used as a reason by the bigger content providers for
holding back production deployment, which is what we all want to see.
> It's time to remove the stabilisers on the IPv6 bicycle.

+1. Let's move on and not repeat this tired discussion.

Cb

---

From: "George, Wesley" <[email-masked]>
Date: Tue, 7 Jun 2011 10:39:51 -0400

At the risk of rehashing discussion from WGLC...
Ole has addressed some of your points, I'll address a few others below inline.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Keith Moore
Sent: Monday, June 06, 2011 1:22 PM
To: [email-masked]
Cc: [email-masked]; IETF-Announce
Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-6to4-to-historic-04.txt> (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC

WEG> Please substantiate these claims. What are the use cases, and why are there no other solutions for those specific use cases? What is considered "widespread ISP support for native IPV6"?

WEG> As was discussed in the WGLC for this document, enterprise applications will not realistically use 6to4 as a means to reach IPv6 for business critical applications. It's simply not reliable enough. It's also probably unlikely that those will go directly to IPv6-only vs using dual-stack to ease that transition. Individuals and Enterprises that use IPv6-only applications will need to make IPv6 service a non-negotiable requirement for their ISPs, networks, and devices rather than hoping that 6to4 works.

WEG> Again, please substantiate this with examples of implementations that are actively using non-relay 6to4. Also, the number of applications of 6to4 that can be guaranteed to avoid any unknown 3rd party relays is extremely limited due to the nature of anycast and 6to4's asymmetric routing. The protocol action requested in this draft in no way prevents one or more consenting networks from using 6to4 and continuing to run relays for their local traffic indefinitely - in fact, it even provides a reference to a document to show them how to make it work as well as possible. It is simply saying that it's not a good idea.

WEG> this seems to be to be splitting hairs. Please explain the distinction you're making here. Disable by default means never use. Use as last resort means use when no better IP connectivity is available. I would think if you insist that 6to4 must stick around you'd prefer it to be enabled. I understand that there are different values of "better" but if 6to4 works, this means that the host is not behind a NAT, and therefore by most definitions, its IPv4 connectivity would be better than 6to4. If it's behind an IPv4 NAT, and therefore IPv6 connectivity would be better (especially if there are one or more applications that work via IPv6 but not via IPv4 + NAT) then 6to4 won't work in lieu of IPv6 connectivity anyway.

Wes George

---

From: Keith Moore <[email-masked]>
Date: Tue, 7 Jun 2011 11:21:05 -0400

> WEG> Please substantiate these claims. What are the use cases, and why are there no other solutions for those specific use cases? What is considered "widespread ISP support for native IPV6"?

The best current use cases for 6to4 that I'm aware of are:

- Applications developers want to be forward thinking and develop IPv6 apps, but cannot get native IPv6 access.  6to4 allows them to develop those apps and test or use them in useful situations (i.e. outside of a lab) without having to configure a separate tunnel to every host involved.   Note that 6to4 is useful in this way even if all of the addresses used are 6to4 addresses, and the traffic therefore does not cross any relays between 6to4 and native IPv6.
- Enterprises have applications that need to be able to communicate with large numbers of hosts spread over a diverse area.  IPv6 is clearly the way that they want to go, but it's not widely available at present.  6to4 provides them with a means of routing traffic to their hosts in the interim until widespread support for IPv6 exists.
- Users (including enterprise users) who have small networks with IPv4 access (generally behind v4 NATs) can use 6to4 to allow them to remotely access individual hosts on those networks.  This can be done either with a NAT that also acts as a v6 router and supports 6to4 as an external connection, or by configuring the NAT to pass protocol 41 to a IPv6 router for the network, internal to the v4 NAT.

Widespread IPv6 support for native IPv6 would be when native IPv6 is available everywhere that IPv4 access is available, from at least one provider, with quality (connectivity, reliability, support) approximately as good as IPv4, and at a reasonable price.  In other words, you can't expect applications to rely on native IPv6 until it's reliably available everywhere that they need to use it.

> WEG> As was discussed in the WGLC for this document, enterprise applications will not realistically use 6to4 as a means to reach IPv6 for business critical applications. It's simply not reliable en…

With respect, the v6ops working group is not in a good position to judge whether enterprise applications will use 6to4.   Operators rarely have a good understanding of what individual application users or developers need.  They tend to focus mostly on the applications that generate the most traffic,  or cause them particular amounts of trouble, or the ones that their biggest customers need.  Problem is, those aren't the only applications that are important.  Every application is important to its users, no matter how much or little traffic (or revenue) it generates.

6to4 is as reliable as IPv4 is, if it isn't asked to cross a relay router.  And there are valid reasons to use 6to4 even where IPv4 connectivity already exists.

Even in cases where 6to4 traffic must cross a relay router, sometimes it's the best solution available.   

> WEG> Again, please substantiate this with examples of implementations that are actively using non-relay 6to4. Also, the number of applications of 6to4 that can be guaranteed to avoid any unknown 3r…

Application implementations shouldn't care whether they're using relay 6to4, non-relay 6to4, or 6to4 at all.  Application implementations should at most care that they're using IPv6 rather than IPv4, and for some applications even this is not appropriate.

Application deployments might well need to care how well their underlying networks work.  Ideally, they shouldn't have to care, but that's the world we're currently living in.

The requested protocol action deprecates 6to4 and discourages its inclusion in future implementations.  That's harmful to applications and users for whom native IPv6 isn't available - which is to say, pretty much everyone at the moment.  When native IPv6 becomes widely available, it will then be appropriate to transition hosts and networks using 6to4 to native IPv6.  But even then, there will probably still be a need for host implementations 

> WEG> this seems to be to be splitting hairs. Please explain the distinction you're making here. Disable by default means never use. Use as last resort means use when no better IP connectivity is available.

I was interpreting "treat 6to4 as a service of last resort" as affecting the address and interface selection algorithm.   If 6to4 is enabled on a host or network, there are reasons to use 6to4 in preference to some other kinds of connectivity.    The question of whether to enable 6to4 should be separate from the question of "if 6to4 is enabled, what priority should it have in address selection?"

Keith

p.s. I'd support the writing of an applicability statement for 6to4 that recommends a narrowing of its applicability to specific use cases, and I'm even willing to help write it.   But moving it to Historic is going too far, and it sends the wrong message.   We need for 6to4 in our toolbox to enable enterprises and applications developers to be able to write and (tentatively, carefully) deploy applications that use IPv6.   We can't afford to wait until all ISPs support native v6 for people to start writing applications that use it.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Jun 2011 03:45:00 +1200

After a fair amount of thought, I have decided that I support
this document without reservation.

I support the recommendation that RFC 3056/3068 support should be off
by default in CPEs; the reasons for this are clear enough in my companion
draft. Specifically, I support the choice of "SHOULD NOT enable" (rather
than MUST NOT) because it leaves open the option for a CPE or host vendor to
enable RFC 3056/3068 by default if there is a sound reason to do so for a
specific product.

I support the recommendation to reclassify RFC 3056 as Historic,
because its time is past. The reason for inventing 6to4 in the
first place was for the benefit of customers whose ISPs could
not deploy IPv6. There is now no reason or excuse for a consumer
ISP to fail to deploy IPv6 for customers, so it is entirely
reasonable to consider the technique as Historic. This has no
impact on current successful use of 6to4 - the recommendation is
to retain existing relays "until traffic diminishes" and to follow
appropriate operational recommendations meanwhile. As my companion
draft indicates, relays advertising the 2002::/16 prefix are needed
as long as there is residual 6to4 traffic in the network.

Regards
   Brian Carpenter (co-author of RFC 3056)

---

From: Keith Moore <[email-masked]>
Date: Tue, 7 Jun 2011 14:20:18 -0400

> I'm loathe to go through this discussion again. let me just respond to some of the points you make, and then agree that we disagree.

I'm also loathe to go through the discussion again.  It shouldn't be necessary.  6to4 has long been useful, and continues to be useful, for some cases.  It's appropriate to document problems with 6to4, perhaps revise its applicability based on experience, and also to publish recommendations for how to manage 6to4 relays, and to urge removal of broken relays and/or filtering of their routing advertisements.   But deprecating it is entirely premature.  (When I recently asked local ISPs when they'll be offering IPv6 support, their answer was "what?". )

> _deployment_ not _support_.

The recommendations of the proposal are overkill anyway.  But assuming there's some merit in writing an applicability statement for 6to4 (and I think there might be), this text should be clearer and more balanced.

And I'm not sure where you get the idea that RFC 3056 recommends that relay operators advertise what parts of the 6to4 space they are routing.  3056 doesn't say anything about BGP advertisements for IPv4, as 3056 assumes there will be a manually configured relay router.   As for advertisement of IPv6 prefixes, the idea has always been that we didn't want to incorporate the v4 routing table into v6, so 3056 specifically says that the only prefix advertised in BGP should be 2002::/16.  (Obviously no such prefix should be advertised if the router isn't willing and able to route to the entire 2002::/16 space, i.e. arbitrary addresses on the public IPv4 network.)

> it is the unmanaged aspect of 6to4 deployment that exhibits the most problems. a manually configured managed point to point tunnel may also be blocked in a firewall, but then the operator will have…

Indeed, that is one of its main virtues.  6to4 decouples application deployment of v6 from network deployment of v6, and helps reduce the "chicken or egg" problem.

(At least, that's the intent.  Reality is that 6to4 does have some impact on the network, at least where relay routers that publicly advertise prefixes through BGP are concerned.  But 6to4 is useful - admittedly in corner cases - even without relay routers.)

> Teredo is similar in many aspects to 6to4, but there is little evidence that it causes the same problems. largely because it is the choice of last resort in implementations and it hasn't/can't be e…

Bogus argument.  Teredo has a different set of problems than 6to4 - higher overhead, not as scalable, dependent on a single provider for relays, not as widely deployed in hosts, etc.  If you're seeing fewer problems with Teredo, it's because it's not used as much as 6to4 is (in part because it has more problems) - not because there are fewer problems with it overall.   In other words, you're blaming 6to4 for its relative success.

I think it's fair to say that 6to4 didn't anticipate the degree to which relay routers and their BGP advertisements need to be monitored, and it failed to make recommendations for this.  But the same is true for IP.  When you get a BGP advertisement for a prefix that goes to a router that drops the packets, you have to deal with it.  When you get a BGP advertisement for a 6to4 router that isn't working properly, you have to deal with that too.  The 6to4 relay problem may appear worse than the normal bogus route advertisement case because all of the 6to4 related bogus BGP advertisements are for the same two address prefixes (one IPv4 and one IPv6).  But from where I sit, I can't tell that it's a worse problem overall.

> 6to4 does not work through IPv4 NATs.

6to4 can work through IPv4 NATs.  Some NATs support 6to4 (and act as NATs for v4, routers for v6).  Other NATs can be manually configured to pass protocol 41, and to have that traffic handled internally to the interior network.

Admittedly, 6to4 does not work though LSN.   I see that as a bug in LSN, if it doesn't provide a well-defined way for customers to get equivalent functionality to 6to4.   

> the purpose of the text in the document is to ensure that the deprecated prefixes are not reused before 6to4 has been phased out.

Just leave the allocation as-is until it really is time to deprecate 6to4.  Frankly I don't expect that to happen for another 5-10 years, but I'd love to be surprised at the rapid acceleration in native IPv6 deployment.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 7 Jun 2011 15:07:46 -0400

> Requested by the AD. The argument for standards track was that it addressed a standards track document. The IESG apparently opines that an informational document will do the job and is their prefer…

FWIW, I agree that it's not appropriate to make a non-protocol document into a Proposed Standard.  On the other hand, I also believe that a reclassification of a Proposed Standard to Historic should require an IETF Consensus action, which is a higher bar than is required for publication as Informational. There's no problem as long as all of the normal process rules for IETF Consensus actions are followed.

(this is of course a separate question from whether the proposal has merit)

Keith

---

From: Martin Rex <[email-masked]>
Date: Tue, 7 Jun 2011 20:50:13 +0200 (MEST)

George, Wesley wrote:
> published as an RFC, 6to4 stops working.

In my personal perception, the "historic" status used to be a technical
characterization to indicate that 

  (1) a protocol or technology has been fully replaced by some newer
      protocol and there is no reason to continue using the original
      technology anymore because the successor can be used in each
      of the original usage scenarios today

  (2) the protocol/technology has been largely put out of use, and its
      active use has dropped to marginal levels (like less than 1% of the
      original active use)

Personally, I have never conciously used anything related to IPv6 so
far, so for me it is difficult to comment, but what has been said
looks to me that neither (1) nor (2) apply to 6to4.

The user base seems to have always been small, and most of the users
of 6to4 simply did _not_ have an alternative -- and its current
users still do _not_ have an alternative today.

Classification of 6to4 as historic is appropriate use of the IETF process,
because it would be a political, but not an accurate technical statement.

-Martin

---

From: "George, Wesley" <[email-masked]>
Date: Tue, 7 Jun 2011 17:27:57 -0400

From: Keith Moore [mailto:[email-masked]]
Sent: Tuesday, June 07, 2011 11:21 AM
To: George, Wesley
Cc: [email-masked]; [email-masked]
Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-6to4-to-historic-04.txt> (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC

KM>The best current use cases for 6to4 that I'm aware of are:

KM>- Applications developers want to be forward thinking and develop IPv6 apps, but cannot get native IPv6 access.  6to4 allows them to develop those apps and test or use them in useful situations (i.e. outside of a lab) without having to configure a separate tunnel to every host involved.   Note that 6to4 is useful in this way even if all of the addresses used are 6to4 addresses, and the traffic therefore does not cross any relays between 6to4 and native IPv6.

WEG> Exactly my point. this is a valid use case, but 6to4 is by no means the only way to solve it. Application developers are welcome to set up an IPv6 network to test their apps against. That doesn't require IPv6 connectivity to the outside world. If you have more than one of any modern computer on your LAN and you turn the right knobs, they can all talk to each other via IPv6 independent of any external IPv6 connectivity. You seem to want to draw this distinction between IPv6 between two hosts using 6to4 since that "works" and using 6to4 as a means to connect to the IPv6 Internet via relays, but then you conflate them by repeatedly complaining about lack of IPv6 service available from most ISPs and presenting 6to4 as a solution.
Further, I don't buy the "separate tunnel to every host..." thing. Tunneled IPv6 connectivity is widely available. All any developer needs to do if they can't get Native IPv6 and a tunneled application is deemed good enough for their testing purposes is connect both ends of their testing environment to their choice of tunnel broker, and through the magic of the internet, they're all connected to one another.

KM> - Enterprises have applications that need to be able to communicate with large numbers of hosts spread over a diverse area.  IPv6 is clearly the way that they want to go, but it's not widely available at present.  6to4 provides them with a means of routing traffic to their hosts in the interim until widespread support for IPv6 exists.

WEG> So do IPv6IP or GRE tunnels. Been using one at home for 3+ years now. And honestly, if this type of application is going to be enterprise-class, it needs to be in conjunction with ISP deployment of IPv6, not in spite of it.

KM> - Users (including enterprise users) who have small networks with IPv4 access (generally behind v4 NATs) can use 6to4 to allow them to remotely access individual hosts on those networks.  This can be done either with a NAT that also acts as a v6 router and supports 6to4 as an external connection, or by configuring the NAT to pass protocol 41 to a IPv6 router for the network, internal to the v4 NAT.

WEG> Until CGN becomes common, in which case 6to4 doesn't work again. Also, that same NAT + v6 router combination could just as easily manage a static tunnel.

KM>Widespread IPv6 support for native IPv6 would be when native IPv6 is available everywhere that IPv4 access is available, from at least one provider, with quality (connectivity, reliability, support) approximately as good as IPv4, and at a reasonable price.  In other words, you can't expect applications to rely on native IPv6 until it's reliably available everywhere that they need to use it.

WEG> So Widespread IPv6 has to have reliability and support equivalent to IPv4, yet you're saying that you can expect applications to rely on 6to4 in the meantime despite evidence that it's unreliable, and the virtual guarantee that it won't be supported by the upstream ISP?
And you and I disagree about the definition of widespread. I do not think that widespread means "every small ISP in every corner of the world supports it ubiquitously and at every price point." I think it means "it's available for a majority (>50%) of Internet service customers."

KM> With respect, the v6ops working group is not in a good position to judge whether enterprise applications will use 6to4.   Operators rarely have a good understanding of what individual application users or developers need.  They tend to focus mostly on the applications that generate the most traffic,  or cause them particular amounts of trouble, or the ones that their biggest customers need.  Problem is, those aren't the only applications that are important.  Every application is important to its users, no matter how much or little traffic (or revenue) it generates.

WEG> I'm not going to touch the "operators don't know what they're talking about" part of your comment, except to note that it's a gross generalization that won't help your argument, and wonder how you are uniquely qualified to know better than the rest of us... I am simply saying that I do not for a second believe that those same applications that are so important to that user community are at the same time unimportant enough that they're the sacrificial lamb that has to go IPv6-only when the majority of that user community, no matter how small, doesn't have native IPv6 access yet. This is the essence of the IPv6 content vs access chicken/egg problem, and 6to4 absolutely will not break the impasse. 6to4 breakage is the most common thing that content providers cite as reasons why they don't just go dual-stack. Why would an enterprise application be any different?

KM> 6to4 is as reliable as IPv4 is, if it isn't asked to cross a relay router.
WEG> perhaps (with the exception of MTU issues that plague any tunneled protocol), but you continue to not provide any examples of this being used anywhere, in the face of significant evidence that 6to4 is horribly unreliable *with* a relay. So this gets filed in the same place as my 100% secure file server which happens to be unplugged from power and network and encased in 10ft of concrete. Theoretically perfect, but otherwise practically useless.

KM> And there are valid reasons to use 6to4 even where IPv4 connectivity already exists.
WEG> One would hope you wouldn't be trying to use 6to4 where IPv4 connectivity *doesn't* exist.

KM>Even in cases where 6to4 traffic must cross a relay router, sometimes it's the best solution available.
WEG> Perhaps, but again, we're talking about such a small percentage of the time that the cure ends up being worse than the disease. I love orphans and lost causes as much as the next guy, but really...

KM>All of the criticisms in section 3 have to do with the use of relays to exchange traffic between 6to4 and native IPv6.   In many cases the criticisms are overbroad.   Not all uses of 6to4 involve relays.  For some of those that do need to use relays, it is not necessarily the case that the relay is operated by an unknown third-party.

KM> Application implementations shouldn't care whether they're using relay 6to4, non-relay 6to4, or 6to4 at all.  Application implementations should at most care that they're using IPv6 rather than IPv4, and for some applications even this is not appropriate.
Application deployments might well need to care how well their underlying networks work.  Ideally, they shouldn't have to care, but that's the world we're currently living in.

WEG> First, you're hair-splitting between implementation and deployment. However you want to call it, I'm referring to "situations" where 6to4 is in use without relays and is performing reliably on a business-critical use to justify your assertion that we shouldn't toss out this part of 6to4 along with the anycast/relay part because it's still so useful.

WEG> I agree that properly written applications are IP version-agnostic. There is only a question of whether they work through one or more layers of IPv4 NAT, or they don't. If they don't, then the solution is IPv6. If IPv6 isn't available, you have many major content providers saying that they absolutely don't see 6to4 as an acceptable substitute, meaning that your supposed application of 6to4 as a fix for this problem is so niche as to be harmful rather than helpful. Why are we having a World IPv6 Day? In part to shake loose the broken 6to4 users that may not even know that 6to4 is enabled/broken so that content providers can be more confident that they can dual-stack their websites without risk of significant user impact due to breakage.

KM> The requested protocol action deprecates 6to4 and discourages its inclusion in future implementations.  That's harmful to applications and users for whom native IPv6 isn't available - which is to say, pretty much everyone at the moment.  When native IPv6 becomes widely available, it will then be appropriate to transition hosts and networks using 6to4 to native IPv6.  But even then, there will probably still be a need for host implementations

WEG> Well, it'd be more harmful if there weren't alternatives. Also, assuming that the protocol is declared historical, we're now in a footrace between ISPs deploying IPv6 and equipment vendors removing support for 6to4 (or rolling out new products that don't support it in the first place). I think you're oversensationalizing both the impact of this draft and the lack of IPv6, given that nearly all major ISPs in the commercial space are currently offering or have a timeline to offer Native IPv6, and a large amount of the ISPs in the residential space have a timeline for deployment, many have already started trials.
Finally, we're having problems with equipment that doesn't support IPv6 at all. 6to4 is not high on the priority list to implement compared with a functional IPv6 stack, meaning that on new gear, it likely won't get implemented until it's no longer necessary.

Wes George

---

From: Keith Moore <[email-masked]>
Date: Tue, 7 Jun 2011 18:47:47 -0400

On Jun 7, 2011, at 5:27 PM, George, Wesley wrote:

> WEG> Exactly my point. this is a valid use case, but 6to4 is by no means the only way to solve it. Application developers are welcome to set up an IPv6 network to test their apps against.

Why are you trying to make life harder for developers of IPv6 applications?  There's no reason at all that an application developer should have to set up a special-purpose network just to test an IPv6 application. 

> That doesn't require IPv6 connectivity to the outside world.

Realistic testing of applications needs to be done on real networks, or a least an approximation to real networks.  Testing IPv6 using 6to4 over public IPv4 obviously isn't perfect, but it's a hell of a lot more realistic than setting up a lab network and confining one's testing to that.

> If you have more than one of any modern computer on your LAN and you turn the right knobs, they can all talk to each other via IPv6 independent of any external IPv6 connectivity. You seem to want to draw this distinction between IPv6 between two hosts using 6to4 since that "works" and using 6to4 as a means to connect to the IPv6 Internet via relays, but then you conflate them by repeatedly complaining about lack of IPv6 service available from most ISPs and presenting 6to4 as a solution.

I've been using 6to4 on a regular, often daily, basis since the late 1990s.   6to4 has allowed me to develop IPv6 applications and test them on real networks, and deploy them in limited circumstances.  6to4 has also allowed me to remotely access computers on my SOHO networks, using any application protocol that I chose to do so, with out-of-the-box hardware and software, without any application-specific proxies, and generally without any application-specific configuration.  None of these scenarios required a relay router.  All of them were, and continue to be, useful.

Yes, I've experienced on many occasions that using 6to4 to access dual-stack web servers doesn't always work so well.  Sometimes it picks a suboptimal path because the relay router isn't convenient.  Sometimes the v6 path doesn't work at all and the application has to time out and retry using v4.   But this never really bothered me much, because my purpose in using 6to4 wasn't to try to access services that I could get to via IPv4 anyway.  And neither, I suggest, is that a reasonable metric for evaluating 6to4 or any other IPv6 transition mechanism.   The metric for evaluating an IPv6 transition mechanism should be based on its effectiveness in accessing services that are IPv6 only.   

And sure, 6to4 is a sort of last resort for those services, except maybe for the other transition mechanisms that are worse: Teredo is often worse, configured tunnels are often worse, for all of the obvious reasons.  If your ISP offers you native IPv6 access you should probably use that instead, even if internally they use 6rd or some other tunneling scheme.  There's definitely benefit to having professional management and support (such as it is) for your IPv6 connectivity.  

Yet, time and time again the argument gets made that 6to4 gets in the way of trying to access such services.  6to4 by itself is not the problem.  The problem is address selection rules that favor v6 over v4.  If the service is supported under v4, if it works fine through any NATs in the signal path, the application should probably use v4 to talk to that service.  And if the service is v6-only, and 6to4 is the best way of getting there that's available, you might as well try to use it.

> Further, I don't buy the "separate tunnel to every host..." thing. Tunneled IPv6 connectivity is widely available. All any developer needs to do if they can't get Native IPv6 and a tunneled applica…

You seem to have this fixed idea of how applications should be tested and used, that is inconsistent with my experience.  "Both" ends of their testing environment?  What gives you the idea that there are only two ends?   Distributed development projects are quite commonplace, and can involve hundreds or even thousands of people, each at different sites.   Nor is there necessarily some sort of central network that everything connects to.  Nor should there be. 

> WEG> So do IPv6IP or GRE tunnels. Been using one at home for 3+ years now. And honestly, if this type of application is going to be enterprise-class, it needs to be in conjunction with ISP deployme…

What you're saying is that applications developers shouldn't bother with actually trying to use IPv6 until the ISPs get their act together and deploy it.  Well guess what?  The ISPs have let us down.  We've been waiting for 15 years for the ISPs to roll out IPv6, and for most of those 15 years they were all telling us that there were no applications for it.  Now the ISPs are scrambling to get IPv6 into their networks, and they want to sabotage the IPv6 mechanisms that we have in place even before they are actually offering product.

> WEG> Until CGN becomes common, in which case 6to4 doesn't work again. Also, that same NAT + v6 router combination could just as easily manage a static tunnel.

You're missing something.   I can connect directly from my mobile laptop to a machine in my home network using 6to4.  I didn't have to set up any static tunnel for either one.  Sure, I could do that, I could get tunnels from HE or some other source and route through them.  Why should I bother?  Why do I want to make my IPv6 traffic take any longer a route than necessary?  You've argued against 6to4 with relay routers because it's routing can be suboptimal, but the same is true of any other tunneling scheme.

> WEG> So Widespread IPv6 has to have reliability and support equivalent to IPv4, yet you're saying that you can expect applications to rely on 6to4 in the meantime despite evidence that it's unrelia…

There's no such virtual guarantee.   

> And you and I disagree about the definition of widespread. I do not think that widespread means "every small ISP in every corner of the world supports it ubiquitously and at every price point." I t…

We can disagree about the meaning of the word "widespread", but the practical fact is that you can't expect people to give up something that works for them until you can provide them something that works better for them.  "Available to 50% of Internet service customers" is equivalent to a very small percent probability of native connectivity being able to replace 6to4 connectivity in a scenario where 6to4 is currently working.  And the more hosts involved, the smaller that probability is. 

> WEG> I'm not going to touch the "operators don't know what they're talking about" part of your comment, except to note that it's a gross generalization that won't help your argument, and wonder how you are uniquely qualified to know better than the rest of us...

Seems to me it's the v6ops people who are making the gross generalizations.  I'm mostly pointing out exceptions to those gross generalizations that have been made here and in v6ops.  

> I am simply saying that I do not for a second believe that those same applications that are so important to that user community are at the same time unimportant enough that they're the sacrificial lamb that has to go IPv6-only when the majority of that user community, no matter how small, doesn't have native IPv6 access yet.

You have absolutely no idea which applications will be important to the user community tomorrow.   Who knows what will be the next netflix, twitter, facebook, youtube, ... ?   The Internet is successful not because it supports some small number of apps that operators think are a good idea; it's successful because it (at least as originally architected) can support a wide range of apps without operators having to bless them. 

> This is the essence of the IPv6 content vs access chicken/egg problem, and 6to4 absolutely will not break the impasse. 6to4 breakage is the most common thing that content providers cite as reasons why they don't just go dual-stack. Why would an enterprise application be any different?

It doesn't really matter much whether "content-providers" (as in web site providers) go "dual stack" now.  Sure, they need to be gearing up for it, making sure that they understand it, making sure that their networks support it.  (Or maybe they'll just install v6-to-v4 proxies at their borders so that they can keep providing good customer service in the face of LSN-induced brain damage on the public v4 network.)   But assuming their applications work through LSN, they're going to keep supporting v4 for a long time anyway, because that's the established base of interoperability for their products and services.   Existing "content providers" are not going to drive adoption of IPv6.   They're going to follow it.  Web and email will be the last applications to migrate.  New content might appear on v6, and that might drive adoption.  But to the extent that it drives adoption, it probably won't be from the currently established players that already have plenty of v4 addresses and infrastructure.  It will be from new things that take advantage of the niches created by IPv6 that didn't exist before.

> WEG> perhaps (with the exception of MTU issues that plague any tunneled protocol), but you continue to not provide any examples of this being used anywhere, in the face of significant evidence that…

What is "anywhere" to you?  You seem to have a content-centric view of the Internet.  I do not.   Meanwhile, you persist in saying that something that I've used regularly for more than 10 years, to do useful work, isn't being used anywhere.   I keep seeing figures that 6to4 comprises 40-some-odd percent of IPv6 traffic, while native IPv6 is around 10 percent.  By your logic, native v6 should be deprecated because it doesn't work reliably and it's not being used anywhere.

> WEG> One would hope you wouldn't be trying to use 6to4 where IPv4 connectivity *doesn't* exist.

Right, but the point is that there are valid use cases for 6to4 even where you have IPv4 connectivity for part or even all of the network that you're using.

> WEG> Perhaps, but again, we're talking about such a small percentage of the time that the cure ends up being worse than the disease. I love orphans and lost causes as much as the next guy, but real…

The disease is the current IPv4 network with NATs and LSNs and a paucity of address space.  6to4 is like a drug that can let some valuable v6 applications grow (even if a bit stunted) and survive until there's once again a network that will support them.  Sure, there are some side effects and contraindications.  But it's useful when used with awareness of its limitations.  You're arguing that it should be discouraged because it causes some problems.  Indeed it does.  But LSN also causes problems, and is a bigger dead-end than 6to4, and it's full steam ahead with that.  At least 6to4 is designed to ease transition to a saner world, which is a lot more than I can say for LSN.

> WEG> First, you're hair-splitting between implementation and deployment. However you want to call it, I'm referring to "situations" where 6to4 is in use without relays and is performing reliably on…

You're attacking 6to4 on the basis of irrelevancies.  As for business-critical, that's up to the business using it to determine whether it works well enough for their purposes.  There are a lot of technically dubious practices used in business critical applications and networks.

> WEG> I agree that properly written applications are IP version-agnostic. There is only a question of whether they work through one or more layers of IPv4 NAT, or they don't. If they don't, then the solution is IPv6. If IPv6 isn't available, you have many major content providers saying that they absolutely don't see 6to4 as an acceptable substitute, meaning that your supposed application of 6to4 as a fix for this problem is so niche as to be harmful rather than helpful.

The notion that "properly written applications are IP version-agnostice" is naive and overbroad.  IPv6 works differently enough from IPv4 that many applications cannot treat them the same.   Simple client-server apps, perhaps, can ignore their differences, but that's just a corner case.   

I have no doubt that many of those "major content providers" are correct when they don't see 6to4 as an acceptable substitute for them.  But the Internet doesn't exist just to support "major content providers".  So stop trying to sabotage something that works well enough for other users.

> Why are we having a World IPv6 Day? In part to shake loose the broken 6to4 users that may not even know that 6to4 is enabled/broken so that content providers can be more confident that they can dual-stack their websites without risk of significant user impact due to breakage.

I'm looking forward to World IPv6 Day, and what will be learned from it.   But again, how well 6to4 works with "major content providers" is irrelevant.

> WEG> Well, it'd be more harmful if there weren't alternatives.

There aren't any good ones.  Teredo and configured tunnels are worse in many ways; though they each have their use cases.   

> Also, assuming that the protocol is declared historical, we're now in a footrace between ISPs deploying IPv6 and equipment vendors removing support for 6to4 (or rolling out new products that don't support it in the first place). I think you're oversensationalizing both the impact of this draft and the lack of IPv6, given that nearly all major ISPs in the commercial space are currently offering or have a timeline to offer Native IPv6, and a large amount of the ISPs in the residential space have a timeline for deployment, many have already started trials.

Gear that doesn't support IPv6 by now is pretty odd gear.     But I'm not going to tell you not to use it.  I'm just saying, if you want odd gear to work for you in your own specific use cases, don't try to sabotage other odd things that work for other people in their specific use cases.

Keith

---

From: Martin Rex <[email-masked]>
Date: Wed, 8 Jun 2011 17:42:10 +0200 (MEST)

I'm sorry, I seem to have goofed up during mail editing...

I meant to write that cassifying 6to4 as historic is INappropriate use
of the IETF process in the last sentence.

-Martin

---

From: "George, Wesley" <[email-masked]>
Date: Wed, 8 Jun 2011 15:28:09 -0400

From: Keith Moore [mailto:[email-masked]]
Sent: Tuesday, June 07, 2011 6:48 PM
To: George, Wesley
Cc: [email-masked]; [email-masked]
Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-6to4-to-historic-04.txt> (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC

KM>I've been using 6to4 on a regular, often daily, basis since the late 1990s.   6to4 has allowed me to develop IPv6 applications and test them on real networks, and deploy them in limited circumstances.  6to4 has also allowed me to remotely access computers on my SOHO networks, using any application protocol that I chose to do so, with out-of-the-box hardware and software, without any application-specific proxies, and generally without any application-specific configuration.  None of these scenarios required a relay router.  All of them were, and continue to be, useful.

KM> Yes, I've experienced on many occasions that using 6to4 to access dual-stack web servers doesn't always work so well.  Sometimes it picks a suboptimal path because the relay router isn't convenient.  Sometimes the v6 path doesn't work at all and the application has to time out and retry using v4.   But this never really bothered me much, because my purpose in using 6to4 wasn't to try to access services that I could get to via IPv4 anyway.  And neither, I suggest, is that a reasonable metric for evaluating 6to4 or any other IPv6 transition mechanism.   The metric for evaluating an IPv6 transition mechanism should be based on its effectiveness in accessing services that are IPv6 only.

WEG> Again, are you or are you not using a relay router? You keep going back and forth.
Bluntly, this isn't about whether you, or anyone else at IETF use 6to4. We are the longest of the long tail; the smallest percentage, the exception to the rule, not the exception that proves the rule. We're network geeks; we're willing to deal with dodgy connectivity or otherwise fiddly methods of doing things to test them and to prove a point. This discussion cannot be about whether the protocol should be preserved because some marginal percentage of folks in IETF use 6to4 successfully. I am not disagreeing that for some value of "work" 6to4 works to reach IPv6-only things. What I am saying is that the very things you illustrate here make it only acceptable for testing, and not for any sort of real substitute for IPv6 connectivity. What user is going to accept +100ms in latency due to suboptimal relay choice, or waiting multiple seconds for IPv6 to time out because 6to4 didn't work in that particular network setup? I think that the evidence says that 6to4 is actually *ineffective* by the evaluation you suggest - a good portion of the time it either utterly fails or provides such degraded service that it may as well not work.

KM> What you're saying is that applications developers shouldn't bother with actually trying to use IPv6 until the ISPs get their act together and deploy it.  Well guess what?  The ISPs have let us down.  We've been waiting for 15 years for the ISPs to roll out IPv6, and for most of those 15 years they were all telling us that there were no applications for it.  Now the ISPs are scrambling to get IPv6 into their networks, and they want to sabotage the IPv6 mechanisms that we have in place even before they are actually offering product.

WEG> Yes, yes, shame on the big, bad ISPs and their lack of deployment. Trust me, I'm as annoyed with the ISPs I've worked for and been a customer of that it is taking so long to get IPv6 out there too.
But...6to4 sabotaged itself. This draft is acknowledging reality that it really didn't work the way we'd hoped. There is no active malevolence here on the part of the ISPs. In fact many of them (us?) have deployed or will be deploying 6to4 relays to improve the customer experience until native service is available, and are supporting the recommendations to make 6to4 suck less in draft-carpenter.

KM>There's no such virtual guarantee.
WEG>I should probably have clarified that by "support" I don't mean "will pass protocol 41 IPv4 packets." I mean "can call and yell at someone when it breaks." Make more sense now?
WEG> I am simply saying that I do not for a second believe that those same applications that are so important to that user community are at the same time unimportant enough that they're the sacrificial lamb that has to go IPv6-only when the majority of that user community, no matter how small, doesn't have native IPv6 access yet.

KM>You have absolutely no idea which applications will be important to the user community tomorrow.   Who knows what will be the next netflix, twitter, facebook, youtube, ... ?   The Internet is successful not because it supports some small number of apps that operators think are a good idea; it's successful because it (at least as originally architected) can support a wide range of apps without operators having to bless them.
WEG> One of the few places I'm in agreement with you. However, it's not a justification for 6to4. It's a justification for ubiquitous IPv6. It's not about whether the operators "bless" an application or not. If those up-and-coming applications are saddled with the performance hit that 6to4 represents, they are unlikely to be successful. In other words, 6to4 will not move the needle on innovative IPv6-only applications, so they're tied to the native IPv6 rollout schedule. Sad, but true.

WEG>This is the essence of the IPv6 content vs access chicken/egg problem, and 6to4 absolutely will not break the impasse. 6to4 breakage is the most common thing that content providers cite as reasons why they don't just go dual-stack. Why would an enterprise application be any different?

KM> It doesn't really matter much whether "content-providers" (as in web site providers) go "dual stack" now.  Sure, they need to be gearing up for it, making sure that they understand it, making sure that their networks support it.  (Or maybe they'll just install v6-to-v4 proxies at their borders so that they can keep providing good customer service in the face of LSN-induced brain damage on the public v4 network.)   But assuming their applications work through LSN, they're going to keep supporting v4 for a long time anyway, because that's the established base of interoperability for their products and services.   Existing "content providers" are not going to drive adoption of IPv6.   They're going to follow it.  Web and email will be the last applications to migrate.  New content might appear on v6, and that might drive adoption.  But to the extent that it drives adoption, it probably won't be from the currently established players that already have plenty of v4 addresses and infrastructure.  It will be from new things that take advantage of the niches created by IPv6 that didn't exist before.
WEG> This is a variant of the old "IPv6 Killer App" discussion. We're still waiting for one, largely because people are afraid of excluding some non-trivial percentage of the populace from being able to use their new, cool thing because it's IPv6-only, and they don't think it will so compelling as to be a justification for people to find a workaround or clamor for IPv6 support. IMO, IPv4 exhaustion and CGN is the closest thing we have to a Killer App for IPv6. If 6to4 somehow provides an incentive for folks to generate IPv6-only applications, and for ordinary users to start using 6to4 to connect to IPv6, I'm wondering why it hasn't accomplished that goal in the last 10 years?What would be different all of the sudden?

KM>What is "anywhere" to you?  You seem to have a content-centric view of the Internet.  I do not.   Meanwhile, you persist in saying that something that I've used regularly for more than 10 years, to do useful work, isn't being used anywhere.
WEG> No, I'm trying to follow the same distinction you've drawn between 6to4 with relays and without and understand how that's being used, since apparently 6to4 without relays is a lot less problematic and you've had such success with it. What I've read is multiple people trying to explain to you that non-anycast 6to4 (3056) is not being used, and you continuing to insist that it's heavily used by providing examples of 3068.

KM>  I keep seeing figures that 6to4 comprises 40-some-odd percent of IPv6 traffic, while native IPv6 is around 10 percent.  By your logic, native v6 should be deprecated because it doesn't work reliably and it's not being used anywhere.
WEG> While my general view is that 40% of less than 1% of Internet traffic amounts to a statistical anomaly, citation, please? Assuming that the source of your statistic is able to distinguish between types of protocol 41 traffic, that 40% is almost definitely traffic that is using a relay, BTW.

KM> The disease is the current IPv4 network with NATs and LSNs and a paucity of address space.  6to4 is like a drug that can let some valuable v6 applications grow (even if a bit stunted) and survive until there's once again a network that will support them.  Sure, there are some side effects and contraindications.  But it's useful when used with awareness of its limitations.  You're arguing that it should be discouraged because it causes some problems.  Indeed it does.  But LSN also causes problems, and is a bigger dead-end than 6to4, and it's full steam ahead with that.  At least 6to4 is designed to ease transition to a saner world, which is a lot more than I can say for LSN.
WEG> LSN is a necessary evil brought on by the lack of ubiquitous IPv6 support, which has many causes. I don't like it either. The thing you are failing to realize is that IETF saying that 6to4 use is a bad idea in no way stops consenting adults from using it in spite of the side effects and contraindications, but it does put a much finer point on those contraindications.

KM> I have no doubt that many of those "major content providers" are correct when they don't see 6to4 as an acceptable substitute for them.  But the Internet doesn't exist just to support "major content providers".  So stop trying to sabotage something that works well enough for other users.
WEG> Not trying to imply that it does. I'm saying that your definition of "works well enough" and the average user's are widely different, making 6to4 a no-op for the average user. The content providers' position on end users trying to use 6to4 to reach their content is an example of that point.

WEG> Why are we having a World IPv6 Day? In part to shake loose the broken 6to4 users that may not even know that 6to4 is enabled/broken so that content providers can be more confident that they can dual-stack their websites without risk of significant user impact due to breakage.

KM> I'm looking forward to World IPv6 Day, and what will be learned from it.   But again, how well 6to4 works with "major content providers" is irrelevant.
WEG> I might argue that this is because 6to4 is largely irrelevant and will become increasingly more so as major ISPs roll out IPv6 in the next 12-18 months. This is about removing barriers to deployment and use of IPv6 for the increasing population of Native IPv6 users, not trying to buff the turd for a tiny (but unfortunately very vocal) minority.

WEG>Finally, we're having problems with equipment that doesn't support IPv6 at all. 6to4 is not high on the priority list to implement compared with a functional IPv6 stack, meaning that on new gear, it likely won't get implemented until it's no longer necessary.

KM> Gear that doesn't support IPv6 by now is pretty odd gear.     But I'm not going to tell you not to use it.  I'm just saying, if you want odd gear to work for you in your own specific use cases, don't try to sabotage other odd things that work for other people in their specific use cases.
WEG> No. As have multiple others, you assume that I am talking about the usual suspects in core routing and enterprise-class networking and servers. The consumer electronics space is WOEFULLY behind by comparison. That's not "odd" gear. And this isn't about me (for some value of me) wanting that gear to work for some corner case application. This is  about me having to support millions of customers who want that gear to work because they don't want to buy replacements for something that they see as working just fine today. See also CGN = necessary evil.

Wes George

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Keith Moore <[email-masked]>
Date: Wed, 8 Jun 2011 16:19:04 -0400

> WEG> Again, are you or are you not using a relay router? You keep going back and forth.

No, I don't keep going back and forth.  I am able to use 6to4 usefully without a relay router.   But I do have the anycast address configured as the relay router, and I find that useful also.

> Bluntly, this isn’t about whether you, or anyone else at IETF use 6to4.

Nor, bluntly, is it about a few big content providers or whomever else you want to label as important.  The internet is a hugely diverse place, and you don't get to dismiss the concerns of people whom you want to label as red herrings.   Again, 40-something percent of the IPv6 traffic that is observed on the net today uses 6to4.  That's about as much as Teredo, it's a hell of a lot more than native v6.  As long as 6to4 is one of the major ways that people get IPv6 connectivity (and it clearly is), it's premature to declare 6to4 historic.

> We are the longest of the long tail; the smallest percentage, the exception to the rule, not the exception that proves the rule. We’re network geeks; we’re willing to deal with dodgy connectivity or otherwise fiddly methods of doing things to test them and to prove a point. This discussion cannot be about whether the protocol should be preserved because some marginal percentage of folks in IETF use 6to4 successfully.

40-something percent of the traffic is not marginal.  The marginal use is, currently, of native IPv6.

> I am not disagreeing that for some value of “work” 6to4 works to reach IPv6-only things. What I am saying is that the very things you illustrate here make it only acceptable for testing, and not for any sort of real substitute for IPv6 connectivity. What user is going to accept +100ms in latency due to suboptimal relay choice, or waiting multiple seconds for IPv6 to time out because 6to4 didn’t work in that particular network setup?

100ms extra latency as compared to what?  Nonexistent v6 service when they need to use v6?   Using v6 for services for which v4 will do just fine?   And in which use cases does that 100ms extra latency apply?  None in the ones I'm seeing today, on IPv6 day.   

You are the one who keeps citing red herrings as evidence that 6to4 should be deprecated.  You want to take the least compelling use cases for IPv6, and when 6to4 performs suboptimally for some of those cases, use that as an excuse to sabotage it.  

> I think that the evidence says that 6to4 is actually *ineffective* by the evaluation you suggest – a good portion of the time it either utterly fails or provides such degraded service that it may as well not work. 

The evidence is that people are using it.  You're trying to subject it to test cases that are largely meaningless - because in those cases IPv6 (of any kind) provides no marginal value in the near term.

> WEG> So do IPv6IP or GRE tunnels. Been using one at home for 3+ years now. And honestly, if this type of application is going to be enterprise-class, it needs to be in conjunction with ISP deployme…

Almost all usage of IPv6 today is in spite of ISPs.   For that matter, a great many successful IPv4 applications today are deployed in spite of ISPs.  Again, ISPs in general have let us down, and 6to4 and Teredo are carrying ~90% of IPv6 traffic.   ISPs are not in a good position to demand that 6to4 be deprecated.  

> WEG> Yes, yes, shame on the big, bad ISPs and their lack of deployment. Trust me, I’m as annoyed with the ISPs I’ve worked for and been a customer of that it is taking so long to get IPv6 out there too.
> But…6to4 sabotaged itself. This draft is acknowledging reality that it really didn’t work the way we’d hoped.

I have no problem with acknowledging the shortcomings of 6to4 and especially of the use of anycast addresses for relay routers.   There are valuable lessons to be learned there.  But face it, a lot of stuff that's widely deployed on the Internet and useful doesn't work as well as we hoped.  We generally don't try to sabotage things that are useful to people.

> There is no active malevolence here on the part of the ISPs. In fact many of them (us?) have deployed or will be deploying 6to4 relays to improve the customer experience until native service is available, and are supporting the recommendations to make 6to4 suck less in draft-carpenter.

That's excellent news.  But the current proposal on the table to deprecate 6to4 is premature, confusing, and harmful to real users.

> WEG>I should probably have clarified that by “support” I don’t mean “will pass protocol 41 IPv4 packets.” I mean “can call and yell at someone when it breaks.” Make more sense now?

So let's narrow the focus on relay routers that advertise anycast addresses.   I think it's clear that they're the major part of the problem with 6to4.    Maybe there is a way to filter out the advertisements for the ones that blackhole traffic; maybe all such advertisements for those prefixes should be filtered and 6to4 users should have to explicitly configure relay routers.   But whatever the fix, this is a fairly narrow problem and it warrants narrow corrective action.

> WEG> One of the few places I’m in agreement with you. However, it’s not a justification for 6to4. It’s a justification for ubiquitous IPv6.

It's not one versus the other.   6to4 is helping to promote ubiquitous IPv6.

> It’s not about whether the operators “bless” an application or not. If those up-and-coming applications are saddled with the performance hit that 6to4 represents, they are unlikely to be successful. In other words, 6to4 will not move the needle on innovative IPv6-only applications, so they’re tied to the native IPv6 rollout schedule. Sad, but true.

There are many applications that can't be widely successful because of NATs, or lack of addresses.  IPv6 (and 6to4) offer those applications a chance to be successful.   6to4 does not inherently represent a performance hit.  In some cases, it provides connectivity to other IPv6 hosts (whether 6to4 or native) where no other connectivity was as easily available (and without having to explicitly set up tunnels that also cause performance hits.)   Some connectivity to IPv6 is generally better than none.   Again, if you try to compare v6 performance to v4 performance, it will be a long time until there are no cases where the v6 performance comes up short.   Those comparisons are meaningless, because the reason to move to 6to4 isn't to get better performance than v6 for applications that already work fine with v4.  It's to enable new kinds of apps that don't work well in a v4 network full of NATs, and to enable new users and new kinds of devices to be able to fully participate in the Internet.

> WEG> This is a variant of the old “IPv6 Killer App” discussion. We’re still waiting for one, largely because people are afraid of excluding some non-trivial percentage of the populace from being able to use their new, cool thing because it’s IPv6-only, and they don’t think it will so compelling as to be a justification for people to find a workaround or clamor for IPv6 support.

Though I have no doubt that some such apps will eventually appear, the case for IPv6 doesn't have to be a single killer app that's visible to everybody.  The Internet isn't only valuable because of killer apps.   B2b communication (e.g. EDI), for instance, isn't any single kind of killer app that people generally recognize.  But it's extremely valuable to society, and it's tremendously impaired by NATs and widespread use of private IPv4 address space.

> IMO, IPv4 exhaustion and CGN is the closest thing we have to a Killer App for IPv6. If 6to4 somehow provides an incentive for folks to generate IPv6-only applications, and for ordinary users to start using 6to4 to connect to IPv6, I’m wondering why it hasn’t accomplished that goal in the last 10 years?What would be different all of the sudden? 

Killer apps are in the eyes of the beholders.  Early adopters of IPv6 are using it in myriad ways that are quite useful to them.   If they can find uses for v6, so can new users, and makers of new products.    It's not necessary for there to be a single killer app that requires v6 that everyone knows about, for IPv6 to be widely useful.

> WEG> No, I’m trying to follow the same distinction you’ve drawn between 6to4 with relays and without and understand how that’s being used, since apparently 6to4 without relays is a lot less problematic and you’ve had such success with it. What I’ve read is multiple people trying to explain to you that non-anycast 6to4 (3056) is not being used, and you continuing to insist that it’s heavily used by providing examples of 3068.

Sorry, that's a complete mischaracterization of everything I have said.    

> WEG> While my general view is that 40% of less than 1% of Internet traffic amounts to a statistical anomaly, citation, please? Assuming that the source of your statistic is able to distinguish betw…

You are as capable of using google as I am.    And the sources I found didn't break the 6to4 traffic down between 6to4-to-6to4 vs. 6to4-to-native (that would definitely have been useful), but your BTW is pure speculation.  My speculation would be the opposite, but that's just based on my personal experience with 6to4.   

(actually it would be nice for such stats to get a full breakdown of the different cases: native to native, native to 6to4, native to Teredo, 6to4 to Teredo, 6to4 to 6to4, Teredo to Teredo)
 
> WEG> LSN is a necessary evil brought on by the lack of ubiquitous IPv6 support, which has many causes. I don’t like it either. The thing you are failing to realize is that IETF saying that 6to4 use is a bad idea in no way stops consenting adults from using it in spite of the side effects and contraindications, but it does put a much finer point on those contraindications.

People who are using 6to4 now might need for new implementations of hardware and operating systems to support it.  This draft explicitly discourages that.  

On a broader level, people have a hard time grasping what it means to 'deprecate' something or to declare it Historic even if the document goes into a fair amount of detail about it.  They tend to get the high-order bit and to misinterpret that.  

> WEG> Not trying to imply that it does. I’m saying that your definition of “works well enough” and the average user’s are widely different, making 6to4 a no-op for the average user. The content providers’ position on end users trying to use 6to4 to reach their content is an example of that point. 

The average user of what?   Of IPv6 apps?  I don't think content providers know squat about the average users of IPv6 apps.  And anything that compares 6to4 performance to IPv4 performance is a red herring, at least as applied to an argument about whether 6to4 or not is justified.  

> WEG> I might argue that this is because 6to4 is largely irrelevant and will become increasingly more so as major ISPs roll out IPv6 in the next 12-18 months. This is about removing barriers to depl…

I'll be happy to abandon use of 6to4 when I can get native (and non-NATted) IPv6 access anywhere I live, anywhere I work, and anywhere I travel.  If that happens in the next 12-18 months I'll be ecstatic.   But I'm not holding my breath.  In 12-18 months I'll be lucky if I can get native v6 access in one of those cases.  For the others, I'll continue to need some kind of tunneling solution, and 6to4 is often the one that works best.   Deprecating 6to4 is imposing a barrier to deployment, not removing one.

> WEG> No. As have multiple others, you assume that I am talking about the usual suspects in core routing and enterprise-class networking and servers.

Where did you get that idea?

> The consumer electronics space is WOEFULLY behind by comparison. That’s not “odd” gear.

If I were to apply your criteria about what justifies use of 6to4 to such devices, they would be odd gear.

> And this isn’t about me (for some value of me) wanting that gear to work for some corner case application. This is  about me having to support millions of customers who want that gear to work because they don’t want to buy replacements for something that they see as working just fine today. See also CGN = necessary evil.

Yes, it's an important problem.     Good luck trying to solve it while you're sabotaging things that work for other people.

Keith

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 8 Jun 2011 02:55:40 -0700

On Jun 7, 2011, at 4:33 AM, TJ wrote:

> Unless you provide IPv6 only sites, you should see very little ... that is part of the point :).
> 
> <snip>
> 
That fails, 20% of time. Seems unlikely that it's going to go away anytime soon, draft or no, that said it seems unwise to keep telling the users and implementors to use it. by default.  
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Dmitry Anipko <[email-masked]>
Date: Wed, 8 Jun 2011 14:32:11 -0700

I don't intend to re-spin the discussion that took place in the WG, but I'd like to say I do agree with the concerns raised in the LC threads by Keith and others. 

If there are 6to4 connectivity issues for some 6to4 clients, in my opinion, those issues would be sufficiently mitigated by RFC 3484/bis. Specifically, by changing priority of 6to4-to-6to4 below IPv4 (the 6to4->native IPv6 is already placed below IPv4 by most or all existing implementations of 3484).

Once priority is changed, 6to4 basically would only be used when it is the only channel that could work to reach a particular destination. Which means that it could provide connectivity, when there would be no connectivity if 6to4 were removed. 

When native IPv6 is made widely available to users, they just would stop using 6to4. So, I don't understand concerns regarding "evolutionary future of 6to4". And it unclear to me why IETF would want to take away a _transition_ technique from people for whom it is working or why there is a need to take any action beyond the recommendations along the lines of RFC 3484/bis.

---

From: Tim Chown <[email-masked]>
Date: Thu, 9 Jun 2011 00:05:08 +0100

> Nor, bluntly, is it about a few big content providers or whomever else you want to label as important.  The internet is a hugely diverse place, and you don't get to dismiss the concerns of people w…

You see 40% of your IPv6 traffic as 6to4, we see rather less than 1%.  Our observation point is as a university on an academic/research network that is native dual-stack.  We probably have most of our IPv6 traffic come from other universities around the world, who are also most likely natively connected.  Hence little if any need for transition methods.  This may be different to your scenario, of course, but it is hopefully a future that will be more widespread in time.

We did use 6to4 in its router-to-router, site-to-site flavour many years ago while a project called 6NET ran, but have had no use case for it since.  Perhaps it would be useful to see your use cases more clearly documented with examples.

> Almost all usage of IPv6 today is in spite of ISPs.   For that matter, a great many successful IPv4 applications today are deployed in spite of ISPs.  Again, ISPs in general have let us down, and 6…

We see even less Teredo, i.e. the sum of the 6to4 and Teredo we see is under 1% of our total IPv6 traffic.  I don't know where you see 90%; I assume it's an environment with home-to-home networks, with no broker or IPv6 VPN use?

> That's excellent news.  But the current proposal on the table to deprecate 6to4 is premature, confusing, and harmful to real users.

The problem is that 6to4 is unfortunately also harmful to real users, at least the ones that don't want to know about IPv6. It will continue to be until we can be confident no vendor anywhere has 6to4 on by default, won't it?

The question is whether Historic stops knowledgeable people like you using 6to4 safely in your own context/community, without affecting 'normal' users.  Does it mean 6to4 off be default, or 6to4 removed from product?

> It's not one versus the other.   6to4 is helping to promote ubiquitous IPv6.

The other view is that 6to4 is delaying ubiquitous IPv6 deployment, by adding brokenness. Geoff's stats illustrate that very well, though those are not based on vanilla 6to4.

Tim

---

From: james woodyatt <[email-masked]>
Date: Wed, 08 Jun 2011 16:20:44 -0700

On Jun 8, 2011, at 2:32 PM, Dmitry Anipko wrote:
> 
> [...] And it unclear to me why IETF would want to take away a _transition_ technique from people for whom it is working...

Let's be very clear.  This proposed RFC would not "take away" the 6to4 transition mechanism.  The working group considered and rejected the idea of publishing a phase-out plan.  This draft sets no new requirements for most current vendors of 6to4-capable equipment.  It is a purely procedural bill, not a technical one.  As such, it will damage no one.

This draft does redundantly make some recommendations that are also made in I-D.ietf-v6ops-6to4-advisory, which is the companion document with technical content intended for audiences other than the IETF itself.  These recommendations mainly say that 6to4 SHOULD NOT be enabled by DEFAULT.  Beyond that, the principle point of this draft is to flip a categorization flag that nobody outside IETF cares about.  The practical effect of that will be to free the authors of future working group drafts from a procedural requirement to consider whether 6to4 poses any special problems for the subjects of future standards efforts.  I'm okay with that, actually, but I have a hard time imagining how it helps them avoid being pragmatic about what's actually deployed in the real world.  Reality must take precedence over public relations, as Professor Feynman said.

After much consideration on this draft, I have concluded that every moment IETF spends arguing over it is one that would be put to better use discussing almost anything else... even which cute word we should use for the colon-separated fields in the IPv6 address presentation format.

Publish it.  Publish it now.  Let its authors be free to pursue more useful ends than defending it.

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

---

From: Keith Moore <[email-masked]>
Date: Wed, 8 Jun 2011 20:31:51 -0400

> You see 40% of your IPv6 traffic as 6to4, we see rather less than 1%.  Our observation point is as a university on an academic/research network that is native dual-stack.  We probably have most of…

I'd love it if we all saw a lot more native IPv6 traffic soon. 

Just to clarify, the 40% is not from my measurement.  It's an approximation to figures I've seen quoted elsewhere.   Like you, I'm sure this figure will vary from place to place.  I haven't tried to do any measurement myself, because the amount of traffic is not a good indicator of overall usefulness.   On the other hand, if any transit provider anywhere in the world is seeing 40% of v6 traffic as 6to4, that is a pretty good indication that somebody (besides myself) is using it.  

For that matter, the very fact that operators are observing problems with relay routers is another indication that people are using 6to4.  Why would they be using it if they didn't want to?   I realize that some platforms enable 6to4 by default, but not all of them do.  And I've already said I support having hosts and routers ship with 6to4 disabled by default.

> We did use 6to4 in its router-to-router, site-to-site flavour many years ago while a project called 6NET ran, but have had no use case for it since.  Perhaps it would be useful to see your use case…

I've already given examples.  People keep looking for more specific examples in an argument where any specific example can be dismissed as irrelevant.  It's not any one specific example that matters, it's the fact that people are using 6to4 and there's not an obviously better replacement that's available to them.

> The problem is that 6to4 is unfortunately also harmful to real users, at least the ones that don't want to know about IPv6. It will continue to be until we can be confident no vendor anywhere has 6…

NATs are harmful to real users too, and they do a lot more harm than 6to4 does.  When will we deprecate them?  When will we declare them Historic?

It's misleading to talk about only the harm being done by 6to4 without acknowledging the benefits of 6to4 or the lack of a suitable alternative.  And to say that 6to4 does harm is misleading.  Is it 6to4 that's doing the harm, or people who advertise routes to relay routers that don't function properly?  Why are people blaming the 6to4 protocol for configuration errors made by network operators?

> The question is whether Historic stops knowledgeable people like you using 6to4 safely in your own context/community, without affecting 'normal' users.  Does it mean 6to4 off be default, or 6to4 re…

Historic doesn't stop someone who can write his own code.  But if it results in implementations removing support for 6to4, declaring 6to4 as Historic will stop people who use those implementations.

> The other view is that 6to4 is delaying ubiquitous IPv6 deployment, by adding brokenness. Geoff's stats illustrate that very well, though those are not based on vanilla 6to4.

I disagree with that assessment, because it's only considering the case of using 6to4 when IPv4 would work just fine.   That's not an appropriate metric.    Nobody who has native IPv6 connectivity needs to use 6to4 to reach native IPv6 destination addresses.   

But a deeper problem is the notion that a single set of address selection rules will work well for all, or even most, applications.

Keith

---

From: Gert Doering <[email-masked]>
Date: Thu, 9 Jun 2011 07:54:47 +0200

Hi,

> Publish it.  Publish it now.  Let its authors be free to pursue more useful ends than defending it.

Well said.  +1

Gert Doering
        -- NetMaster

---

From: Keith Moore <[email-masked]>
Date: Thu, 9 Jun 2011 10:37:56 -0400

> Let's be very clear.  This proposed RFC would not "take away" the 6to4 transition mechanism.  The working group considered and rejected the idea of publishing a phase-out plan.  This draft sets no…

I have also seen those claims in v6ops email (haven't caught up with all of it, but have seen a few messages).  I don't buy the argument.  Clearly the intent of this draft and protocol action are to discourage use of 6to4, particularly in new implementations.  You can't discourage use of 6to4 in new implementations without harming people who are already using it and depending on it.    

(That would be a bit like declaring IPv4 Historic and discouraging new implementations from supporting it - when we all know that there will be people using IPv4 in corner cases for many years even after the public Internet no longer routes it.  Legacy hardware and software that's still in use, etc.)

When the draft is clearly intended to do harm to 6to4, and there are clearly people using 6to4 in the Real World, it strikes me as disingenuous for its proponents to claim that the document will do no harm.

> Publish it.  Publish it now.  Let its authors be free to pursue more useful ends than defending it.

The authors are already free to abandon the effort and pursue more useful ends.  Not only would publishing this do harm to 6to4 and its users, it would set a bad precedent.   We're supposed to be working toward consensus, not trying to cause harm to things that people use.

Keith

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Thu, 9 Jun 2011 16:59:09 +0200

Its 'rough' consensus...
I don't wanna rat-hole here, but imho send the draft onwards for
publication asap please.

G/

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Keith Moore
Sent: 09 June 2011 16:38
To: james woodyatt
Cc: [email-masked] WG; [email-masked]
Subject: Re: [v6ops] Last Call:
<draft-ietf-v6ops-6to4-to-historic-04.txt>(Request to move Connection of
IPv6 Domains via IPv4Clouds (6to4) to Historic status) to Informational
RFC

On Jun 8, 2011, at 7:20 PM, james woodyatt wrote:

>> [...] And it unclear to me why IETF would want to take away a
_transition_ technique from people for whom it is working...
> 
> Let's be very clear.  This proposed RFC would not "take away" the 6to4
transition mechanism.  The working group considered and rejected the
idea of publishing a phase-out plan.  This draft sets no new
requirements for most current vendors of 6to4-capable equipment.  It is
a purely procedural bill, not a technical one.  As such, it will damage
no one.

I have also seen those claims in v6ops email (haven't caught up with all
of it, but have seen a few messages).  I don't buy the argument.
Clearly the intent of this draft and protocol action are to discourage
use of 6to4, particularly in new implementations.  You can't discourage
use of 6to4 in new implementations without harming people who are
already using it and depending on it.    

(That would be a bit like declaring IPv4 Historic and discouraging new
implementations from supporting it - when we all know that there will be
people using IPv4 in corner cases for many years even after the public
Internet no longer routes it.  Legacy hardware and software that's still
in use, etc.)

When the draft is clearly intended to do harm to 6to4, and there are
clearly people using 6to4 in the Real World, it strikes me as
disingenuous for its proponents to claim that the document will do no
harm.

> Publish it.  Publish it now.  Let its authors be free to pursue more
useful ends than defending it.

The authors are already free to abandon the effort and pursue more
useful ends.  Not only would publishing this do harm to 6to4 and its
users, it would set a bad precedent.   We're supposed to be working
toward consensus, not trying to cause harm to things that people use.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 9 Jun 2011 11:05:29 -0400

> I don't wanna rat-hole here, but imho send the draft onwards for

I'm not even sure it's rough consensus within the v6ops group.  Again, haven't read all of the messages, but definitely get the impression that it falls short of consensus.

And just to be clear on procedure:

- you need more than rough consensus in v6ops, you need rough community-wide consensus.  
- the criteria for standards track actions (which this is, despite the document being labeled as Informational) requires both rough consensus and technical soundness.

The best way to not rat-hole is just to drop the proposed action.  

Keith

---

From: Gert Doering <[email-masked]>
Date: Thu, 9 Jun 2011 17:16:40 +0200

Hi,

> The best way to not rat-hole is just to drop the proposed action.  

One voice doesn't make it "consensus to drop".

Gert Doering
        -- NetMaster

---

From: Philip Homburg <[email-masked]>
Date: Thu, 09 Jun 2011 17:18:25 +0200

In your letter dated Thu, 9 Jun 2011 10:37:56 -0400 you wrote:
>I have also seen those claims in v6ops email (haven't caught up with all of it
>, but have seen a few messages).  I don't buy the argument.  Clearly the inten
>t of this draft and protocol action are to discourage use of 6to4, particularl
>y in new implementations.  You can't discourage use of 6to4 in new implementat
>ions without harming people who are already using it and depending on it.    
>
>(That would be a bit like declaring IPv4 Historic and discouraging new impleme
>ntations from supporting it - when we all know that there will be people using
> IPv4 in corner cases for many years even after the public Internet no longer 
>routes it.  Legacy hardware and software that's still in use, etc.)
>
>When the draft is clearly intended to do harm to 6to4, and there are clearly p
>eople using 6to4 in the Real World, it strikes me as disingenuous for its prop
>onents to claim that the document will do no harm.

I think this is likely to happen anyway. In all discussions it has been come
clear that 6to4 has nothing to offer for ordinary users, and that the situation
is going to get worse over time (more NAT, more broken 6to4 installation).

So for any CPE manufacturer is makes perfect sense to start planning on
dropping support for 6to4 in future CPEs, or not add it at all, if they have
yet to release firmware with IPv6 support.

This is independent of whether the protocol is declared historic.

On the other hand, there is no reason why open source distribution would 
have to drop 6to4 support. As long as there are people to maintain it, it
can stay. Also on other operation systems, as long as there is some sort of
tunnel interface, you can implement 6to4. It is just a few lines of code, 
everybody can do it.

So I don't see the big fuzz. If you want to use it, just create a web page
that lists software implementation of 6to4 for every possible platform. And
let the authors of the software know have much their software is appreciated.

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 9 Jun 2011 08:19:55 -0700

> I'm not even sure it's rough consensus within the v6ops group.  Again, haven't read all of the messages, but definitely get the impression that it falls short of consensus.

If you disagree the wg chairs conclusions as far as the wg process outcome and the document shepherds report which can you can find here:

https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/history/

Then you should consider talking to the responsible ad or an appeal to the IESG. As far as I am concerned the accusation that the process has gone off the rails is a seperate issue from the merits or lack thereof of the proposal.

> - you need more than rough consensus in v6ops, you need rough community-wide consensus.  

This is an ietf last call... 

> - the criteria for standards track actions (which this is, despite the document being labeled as Informational) requires both rough consensus and technical soundness.

Informational status was at the behest of the iesg, we have been advised that an informational document may confer historical status on a standards track document.

---

From: Roger Jørgensen <[email-masked]>
Date: Thu, 9 Jun 2011 17:24:12 +0200

> I'm not even sure it's rough consensus within the v6ops group.  Again, haven't read all of the messages, but definitely get the impression that it falls short of consensus.

There were quite heavy discussion and in the end, there were a few
that was totally against it, the rest supported the document.

No point in repeating that entire discussion here really, go back and
look at the archive.

> The best way to not rat-hole is just to drop the proposed action.

Let's take a few step back and think about what we are trying to
achieve here, what is our goal.
IPv6 for everyone for any price? A IPv6 only world? A world where both
IPv4 and IPv6 work or?

I will claim our goal is native IPv6 along IPv4, and in the long run, IPv6 only.
We don't need more tunneling of IPv6 over IPv4, that was okay 10years
ago, maybe even 5 or 3 years ago.
Now it is time to actual do the right thing and say "let's do it
properly, let's do IPv6 native".

...and stop discussing yesterdays technology.

-- 

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

---

From: Keith Moore <[email-masked]>
Date: Thu, 9 Jun 2011 11:42:37 -0400

> is going to get worse over time (more NAT, more broken 6to4 installation).

I don't buy the notion that "ordinary users" only use some small number of killer apps.  "ordinary users" are quite diverse.

I certainly agree that increased deployment of LSN will do harm to 6to4 and its users.  This wouldn't bother me if ISPs were going to roll out a native v6 solution concurrently with LSNs, but my impression is that v6 support is going to lag LSN imposition.

> yet to release firmware with IPv6 support.

I agree that v4 CPE manufacturers, at least those for consumer applications where the networks are likely to be saddled with LSN, certainly should not automatically enable 6to4 in their products.  

There's some justification for their not implementing it at all.  However it's my experience that "consumer" CPEs are often used to provide connectivity for small business customers also.  In general, LSN is not suitable for those customers, and they could benefit from 6to4 support in the CPE.

But I'm more concerned about the potential for this action to result in 6to4 support being prematurely removed from hosts, than I am about its effects on CPEs.  

> tunnel interface, you can implement 6to4. It is just a few lines of code, 

"A few lines of code" imposes a significant barrier.  I've done a fair amount of kernel hacking in the past, written device drivers, and brought up Linux and FreeBSD and NetBSD (in that order) on laptops back in the days when laptop hardware was really flaky and poorly documented and there was no support in the kernels for their network interfaces.  I'm not scared of writing kernel-level C code.  But I don't do it all the time, and realistically it would take me several days to fetch the source code, update myself on the build process, and figure out exactly how to re-insert 6to4 into the kernel.   And that's for Linux or NetBSD - I have less familiarity with MacOS and other kernels.  And I'd have no idea about how to retro-fit 6to4 into Windows if support for it were removed.  I generally don't write code for Windows, but I am occasionally forced to use it.

And somehow I suspect that my skills in this area are considerably more than the typical 6to4 user.

> let the authors of the software know have much their software is appreciated.

Similarly, I don't see why there's such a desire to deprecate 6to4 and declare it Historic.   It's the first time I can recall a proposal to move something to Historic that was widely deployed, widely used, and for which there was no suitable and widely available replacement.

Nor do I understand why, in an organization that is supposedly about building consensus, there's such a demand for a divisive and obviously harmful action.  Generally the way you build consensus is by focusing on things for which there is wide agreement, and crafting compromises on the other things.   But the proponents of this draft have taken a 'no compromise' position.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 9 Jun 2011 11:50:56 -0400

> Then you should consider talking to the responsible ad or an appeal to the IESG. As far as I am concerned the accusation that the process has gone off the rails is a seperate issue from the merits…

I agree that it's a separate issue, and should be treated separately.  Again, I haven't read all of the discussion, probably won't have time to do that for several more days, and will withhold a decision about any process appeal until I've done so.  

(And frankly, if IESG wants to sabotage 6to4 also, I doubt that a process appeal would do any good.  I'll argue vigorously for something that I think is useful and/or important, but I have no interest in making hard-working people's lives harder for no good reason.)

> This is an ietf last call... 

indeed.  I just wanted to counter the possibly-implied assertion that v6ops rough consensus was sufficient.

> Informational status was at the behest of the iesg, we have been advised that an informational document may confer historical status on a standards track document.

I don't have a problem with the idea that an Informational document can describe the consequences of moving something to Historic.  I have a serious problem with the idea that a standards-track document can be moved off of the standards track by less than an IETF Consensus process, or by ignoring the criteria for standards-track actions.  I haven't seen any evidence that IESG is trying to do that - they are doing a Last Call after all.  But I don't think we want to set a precedent that removing something from the standards track is easier or requires less scrutiny of the technical criteria than putting something on the standards track.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 9 Jun 2011 11:54:16 -0400

> properly, let's do IPv6 native".

The time to actually do the right thing was also 10-15 years ago.  But native v6, for the most part, is still not here yet.  At least the ISPs are saying Real Soon Now, which is something.  But who knows what "Real Soon" means?   Until native IPv6 is actually here, where "here" means "everywhere", there is still a need to do tunneling of v6 over v4.

> ...and stop discussing yesterdays technology.

We're always discussing yesterday's technology.   IPv6 was approved in 1995, if I recall.  

Keith

---

From: Christian Huitema <[email-masked]>
Date: Thu, 9 Jun 2011 16:01:39 +0000

Arguably, transitions technologies like 6to4 and Teredo have already achieved their purpose. My goal at the time, more than 10 years ago, was to break the "chicken and egg" deadlock between application developers and network administrators. That's why I spent such energy on making 6to4 easy to deploy, or defining Teredo. Transitions technologies convinced developers that applications could be developed for IPv6 without waiting for every network to be ready, and applications were indeed developed by Microsoft and others. Network administrators in the meantime started deploying IPv6, and the presence of applications arguably helped somewhat -- although I am sure network administrators add many other motivations.

We are now observing a strong pushback, because massive use of tunneling technologies makes networks harder to manage. Wide scale deployment of self-configuring technologies makes levels of services less predictable, and errors are hard to correct. Self-configuring technologies rely largely on the good will of others, which is easier to find during a pioneering phase. Arguably, we are beyond the pioneering phase for IPv6.

I understand Keith's point of view, but it is probably time to start progressively rolling back the transition technologies. 6to4 is the weakest of these technologies. It does not traverse NAT, it does not include configuration verification tests, and it uses asymmetric paths. It makes sense to start the rollback with 6to4.

-- Christian Huitema

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 9 Jun 2011 09:17:13 -0700

> I don't have a problem with the idea that an Informational document can describe the consequences of moving something to Historic.  I have a serious problem with the idea that a standards-track doc…

The record will show that that the intended status of the document until it reached the iegs was standards track. it has been understood from the outset that advancement of the document was to obsolete 3056 and 3068. revision 4 at the request of the iesg changed th e intented status to informational.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Jun 2011 04:29:41 +1200

Philip,

On 2011-06-10 03:18, Philip Homburg wrote:
...
> clear that 6to4 has nothing to offer for ordinary users, 

In all fairness, that depends on your definition of "ordinary".
Where I differ from Keith is that I don't think we harm the current
ordinary (or extraordinary) 6to4 users by relabelling the RFCs.

As long as all operators do what draft-ietf-v6ops-6to4-advisory
suggests, of course. I wouldn't support the -historic draft if
the -advisory draft wasn't coming along too.

> and that the situation

More NAT44, yes. But *less* broken 6to4 if operators implement -advisory.

   Brian

---

From: Keith Moore <[email-masked]>
Date: Thu, 9 Jun 2011 13:20:36 -0400

> ordinary (or extraordinary) 6to4 users by relabelling the RFCs.

At best, I think it's a waste of time.  At worst, I think it will do harm by reducing the number of host implementations that can use 6to4, before native IPv6 is widely available.

In between those extremes, I think there's a large potential for confusion from the publication of 6to4-advisory along with declaring 6to4 historic and discouraging new implementations.   On one hand, we're telling people how to make 6to4 work better.  On the other hand, we're telling people that it's bad and that they shouldn't implement it.  While I've long favored the idea that IETF needs a way to say "this protocol/practice causes problems and we'd rather you not use it, but if you do use it please do it this way", in this case we're trying to do it with two different documents that say somewhat contradictory things to one another.    

Really I think that 6to4-advisory should be sufficient.   That, and it's much better written and more balanced.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 9 Jun 2011 13:26:37 -0400

> The record will show that that the intended status of the document until it reached the iegs was standards track. it has been understood from the outset that advancement of the document was to obso…

And Informational status *for the document*, if published, is entirely appropriate.  But the *protocol action* is a standards-track protocol action.

It used to not be considered necessary to publish an RFC every time the IESG approved a protocol action.   Somewhere along the way, having a companion document started to be commonplace.  I'm not sure why that got to be conventional - maybe it was because of increased use of tracking tools that were written with document processing in mind.  And at least sometimes it's beneficial to the community to publish an RFC that explains why a particular document's status has changed, and how to interpret that change in document status.  But RFC 2026 didn't anticipate the need for every protocol action to have an associated document, and sometimes - as in this case - it causes confusion when they are associated.

Process-wise, I think that the protocol action and the document action should be separate items.  Though of course it makes no sense for IESG to approve the document if it doesn't approve the protocol action.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 9 Jun 2011 13:39:07 -0400

> We are now observing a strong pushback, because massive use of tunneling technologies makes networks harder to manage. Wide scale deployment of self-configuring technologies makes levels of service…

It's hard to argue that we're beyond the pioneering phase of IPv6 when native IPv6 is still not widely available.  The pushback was predictable, for the very reasons you cite.  But it's premature and counterproductive to cave in to it.  If pain associated with 6to4 provides an additional incentive for ISPs to deploy native v6, and for users to use native v6 when it becomes available, that's a Good Thing.  (Not that I want to cause them pain, but neither do I want the Internet to be stuck with 6to4 and Teredo forever.)

> I understand Keith's point of view, but it is probably time to start progressively rolling back the transition technologies. 6to4 is the weakest of these technologies. It does not traverse NAT, it…

The time to start rolling back the transition technologies is when v6 support is available off the shelf.  Because there is some pain associated with them, there's a built in incentive to do so. 

And I disagree that 6to4 is the weakest of the technologies.   They all have strengths and weaknesses.  6to4 is very widely implemented, is automatically configurable, needs no central server, and routing is near-optimal for 6to4-to-6to4 traffic.  But there's a community learning curve associated with using anycast addresses for relay routers.  Configured tunnels take a latency hit on every packet, no matter where it's going.  Teredo works through NATs (good), but also requires routing packets through third party servers, with the corresponding implications for latency, privacy, etc.  And in practice, it's pretty much a Microsoft-only solution - it doesn't ship with either Mac or Linux.

(If we could have developed a universal best-of-breed transition technology, I think we would have done so.   But the solution space really didn't permit that, so we ended up with a hodgepodge of different tools that are applicable in different  situations.)

Keith

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Jun 2011 10:42:17 -0700

On Tue, Jun 7, 2011 at 11:20 AM, Keith Moore <[email-masked]>wrote:

> Indeed, that is one of its main virtues.  6to4 decouples application
> deployment of v6 from network deployment of v6, and helps reduce the
> "chicken or egg" problem.
>

No, it does not - in fact, it is the opposite.

Geoff has presented data that shows that anycasted 6to4 as a connectivity
mechanism has a failure rate of the order of 20-30%. We have data that
clearly shows that Mac OS 10.6.4, which uses 6to4 by default, has a ~50x
greater failure rate when connecting to dual-stack servers than Mac OS
10.6.5 - and the only change is to not use 6to4 by default. Search the list
archives for details.

So the existence of 6to4 is in itself a significant barrier for IPv6
deployment for server operators and content providers. And if you believe
the access networks, the lack of IPv6 content is one of the most significant
barriers to IPv6 deployment in access networks.

Application developers should develop using manually configured tunnels, not
6to4. At least they don't have a 20% failure rate.

---

From: Keith Moore <[email-masked]>
Date: Thu, 9 Jun 2011 13:57:57 -0400

On Jun 9, 2011, at 1:42 PM, Lorenzo Colitti wrote:

> On Tue, Jun 7, 2011 at 11:20 AM, Keith Moore <[email-masked]> wrote:
> Geoff has presented data that shows that anycasted 6to4 as a connectivity mechanism has a failure rate of the order of 20-30%.

I don't dispute that data.  I just disagree with the notion of discouraging 6to4 in its entirety because of the current problems with advertising 6to4 relay routers using anycast addresses.

I suspect that the anycast issues will largely be sorted out before this document can have much of an effect.  But nevertheless, I don't have a problem with discouraging this use of anycast.  I think it was a noble experiment, and we learned something valuable:  Don't use anycast to advertise a service that is provided by a wide range of players, at least not without having some fairly clear guidelines about how to monitor them and weed out the broken ones.

> We have data that clearly shows that Mac OS 10.6.4, which uses 6to4 by default, has a ~50x greater failure rate when connecting to dual-stack servers than Mac OS 10.6.5 - and the only change is to not use 6to4 by default. Search the list archives for details.

Again, I have no problem with implementations disabling 6to4 by default.  Especially given the looming threat of LSN, I became convinced that it was the right thing to do.

> So the existence of 6to4 is in itself a significant barrier for IPv6 deployment for server operators and content providers.

non sequitur.   Existing server operators and content providers can easily provide 6to4 addresses for their servers and content, which will be used in preference to native v6 addresses.

> Application developers should develop using manually configured tunnels, not 6to4. At least they don't have a 20% failure rate.

How do you know?  How do you even measure the failure rate of manually configured tunnels in the aggregate?  I don't think you can monitor that kind of traffic the way you can 6to4, because the traffic patterns are much more constrained.   It's been awhile since I used manually configured tunnels (from a well-known tunnel broker).  But the one time I did try them, 6to4 worked better overall - lower latency and lower failure rate.

Keith

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Jun 2011 10:59:42 -0700

On Tue, Jun 7, 2011 at 3:47 PM, Keith Moore <[email-masked]>wrote:

> Why are you trying to make life harder for developers of IPv6 applications?
>  There's no reason at all that an application developer should have to set
> up a special-purpose network just to test an IPv6 application.
>

No, we're trying to make their lives easier, by suggesting they use
something that actually *works*.

> Realistic testing of applications needs to be done on real networks, or a
> least an approximation to real networks.  Testing IPv6 using 6to4 over
> public IPv4 obviously isn't perfect, but it's a hell of a lot more realistic
> than setting up a lab network and confining one's testing to that.
>

So use a tunnel broker.

> You're missing something.   I can connect directly from my mobile laptop to
> a machine in my home network using 6to4.
>

Really? From where? On none of the networks my laptop connects to do I get a
public IPv4 address. Some of them do give me have native IPv6 or
manually-tunneled IPv6 though.

We can disagree about the meaning of the word "widespread", but the
> practical fact is that you can't expect people to give up something that
> works for them until you can provide them something that works better *for
> them.  "Available to 50% of Internet service customers" is equivalent to a
> very small percent probability of native connectivity being able to replace
> 6to4 connectivity in a scenario where 6to4 is currently working.  And the
> more hosts involved, the smaller that probability is. *
>

You cannot claim that 6to4 is "working" when there is data that shows that
it has a 20% failure rate. If we had that sort of connectivity in IPv4, we
wouldn't have an Internet.

> Existing "content providers" are not going to drive adoption of IPv6.
> They're going to follow it.
>

Nope. Look at World IPv6 day. If you look at the list of participaints, I'd
say that probably more than 10% of Internet content, either by bits or by
query volume, is ready for IPv6 now. Our data shows that access is at 0.3%.
So you could say that in fact content *is* driving adoption of IPv6. We just
need to get unreliable tunneled connectivity out of the way so we can turn
it on for real.

>  Web and email will be the last applications to migrate.
>

Um, no. See above.

> There aren't any good ones.  Teredo and configured tunnels are worse in
> many ways; though they each have their use cases.
>

Actually, configured tunnels are much better. They have a much lower failure
rate and lower latency. We published data that shows the latency impact in
our PAM 2009 paper.

Regards,
Lorenzo

---

From: james woodyatt <[email-masked]>
Date: Thu, 09 Jun 2011 11:01:22 -0700

On Jun 9, 2011, at 7:37 AM, Keith Moore wrote:
> 
>  Clearly the intent of this draft and protocol action are to discourage use of 6to4, particularly in new implementations.  You can't discourage use of 6to4 in new implementations without harming people who are already using it and depending on it.

After it became clear to me that IETF will not be issuing a phase-out plan for 6to4, I recommended to all the relevant product managers at Apple that we should continue supporting 6to4 in new implementations for the foreseeable future (despite the non-RFC2119 'not recommended' line in section 1).

I don't see why this draft should discourage anyone from continuing to support 6to4, which as you point out is a *uniquely* useful protocol that people depend on and find *irreplaceable*.  Reclassifying it as Historic simply allows IETF working groups to operate on the fiction that 6to4 will eventually disappear someday in the indefinite and vaguely hopeful future.  While I don't think that self-delusion will be a good thing for IETF in the long run, I have a hard time getting too bummed out about it.  Pragmatism will find its way into deliberations.

Yes, I think this draft is a pointless waste of time.  The reason I support publishing it, however, is that I disagree with your assessment of the harm it could do.  Also, it enjoys widespread support in the V6OPS working group and the opposition, while vocal, seems quite small.  That looks like rough consensus to me, and if I can help get it off our agenda sooner by supporting it rather than opposing it, then I say let's print it.

I confidently predict the reclassification to Historic will be roundly ignored not just by Apple product engineering but by the entire industry.  We're smart enough to recognize that we're not the target audience for the RFC.  The draft that matters is the companion advisory draft.  It would be nice if the 6to4-to-historic draft could be spiked so as not to distract from its companion, but I don't see that as a likely outcome.  Alas and alack.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Jun 2011 11:10:17 -0700

On Wed, Jun 8, 2011 at 1:19 PM, Keith Moore <[email-masked]>wrote:

> Again, 40-something percent of the IPv6 traffic that is observed on the net
> today uses 6to4.
>

Please point at the data behind that assertion. In many cases in the past,
such assertions have comes from networks that do not have the hardware
capabilities to monitor native IPv6 traffic. I remember one case at the RIPE
meeting where someone from AMS-IX observed about one of these presentations,
"I have more native IPv6 traffic on my exchange point than you have observed
in the entire Internet. How is that possible?" Needless to say, that
presentation did not go well.

Look at http://www.google.com/intl/en/ipv6/statistics/ That obviously does
not see peer-to-peer traffic, but it does see IPv6 web clients, and just
under 90% of those are native.

The evidence is that people are using it.  You're trying to subject it to
> test cases that are largely meaningless - because in those cases IPv6 (of
> any kind) provides no marginal value in the near term.
>

So far, you have provided solid evidence that *you* use it, but not solid
evidence that "people" are using it. Can you point to that evidence?

> Almost all usage of IPv6 today is in spite of ISPs.   For that matter, a
> great many successful IPv4 applications today are deployed in spite of ISPs.
>  Again, ISPs in general have let us down, and 6to4 and Teredo are carrying
> ~90% of IPv6 traffic.   ISPs are not in a good position to demand that 6to4
> be deprecated.
>

Nope. As before, 90% of IPv6 is native, and it comes from a small number of
large deployments. Maybe your ISP doesn't support it, but other ISPs do.

> It's not one versus the other.   6to4 is helping to promote ubiquitous

No, it is a barrier to ubiquitous IPv6 adoption.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Jun 2011 11:20:02 -0700

On Thu, Jun 9, 2011 at 10:57 AM, Keith Moore <[email-masked]>wrote:

> deployment for server operators and content providers.
>
> non sequitur.   Existing server operators and content providers can easily
> provide 6to4 addresses for their servers and content, which will be used in
> preference to native v6 addresses.
>

No. According to Geoff's data, one of the main reasons 6to4 fails is a
firewall that blocks IPv4 protocol 41 traffic. Even if content providers
published 6to4 addresses, those connections would still fail.

> Application developers should develop using manually configured tunnels,
> not 6to4. At least they don't have a 20% failure rate.
>
> How do you know?  How do you even measure the failure rate of manually
> configured tunnels in the aggregate?
>

In a similar way as Geoff measured 6to4 - looking at SYNs. I suspect that
the answer will be that much fewer users have configured tunnels than 6to4,
and that the failure rate is much lower.

>  I don't think you can monitor that kind of traffic the way you can 6to4,
> because the traffic patterns are much more constrained.   It's been awhile
> since I used manually configured tunnels (from a well-known tunnel broker).
>  But the one time I did try them, 6to4 worked better overall - lower latency
> and lower failure rate.
>

Please try again. You will be pleasantly surprised.

---

From: Keith Moore <[email-masked]>
Date: Thu, 9 Jun 2011 14:37:39 -0400

On Jun 9, 2011, at 2:20 PM, Lorenzo Colitti wrote:

> On Thu, Jun 9, 2011 at 10:57 AM, Keith Moore <[email-masked]> wrote:
> No. According to Geoff's data, one of the main reasons 6to4 fails is a firewall that blocks IPv4 protocol 41 traffic. Even if content providers published 6to4 addresses, those connections would still fail.

I suppose we should just tunnel the whole IPv6 network over IPv4 + HTTP then.

Seriously, the argument that 6to4 should be trashed because ISPs are blocking tunnels has the flavor of "don't solve the problem, but rather, stamp out the solution". 

(And of course if the ISPs block protocol 41, that will also kill configured tunnels that happen to transit their networks.  The overall failure rate will be the same, but the granularity of failure will be higher for the configured tunnels.)

> How do you know?  How do you even measure the failure rate of manually configured tunnels in the aggregate?
> 
> In a similar way as Geoff measured 6to4 - looking at SYNs.

From where?   Again, the tunnels aren't taking the variety of paths that 6to4 connections are.  It's that variety that makes measurements such as Geoff's at all useful - it's what lets you at least believe that the measurements made at a few points are representative of the whole.
 
>  I don't think you can monitor that kind of traffic the way you can 6to4, because the traffic patterns are much more constrained.   It's been awhile since I used manually configured tunnels (from a well-known tunnel broker).  But the one time I did try them, 6to4 worked better overall - lower latency and lower failure rate.
> 

A few months ago I was trying to set one up, but I ran out of time.   I'm really busy these days, and it's nowhere nearly as easy to set up a configured tunnel as it is to set up 6to4.

Keith

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Jun 2011 11:45:54 -0700

On Thu, Jun 9, 2011 at 11:37 AM, Keith Moore <[email-masked]>wrote:

> Seriously, the argument that 6to4 should be trashed because ISPs are
> blocking tunnels has the flavor of "don't solve the problem, but rather,
> stamp out the solution".
>

Actually, this mostly happens in enterprise networks and universities. I
don't see why they would want to change this compared to, say, actually
deploying native IPv6.

>
>
> From where?   Again, the tunnels aren't taking the variety of paths that
> 6to4 connections are.  It's that variety that makes measurements such as
> Geoff's at all useful - it's what lets you at least believe that the
> measurements made at a few points are representative of the whole.
>

>From the same place that he ran the 6to4 measurements from?

> A few months ago I was trying to set one up, but I ran out of time.   I'm
> really busy these days, and it's nowhere nearly as easy to set up a
> configured tunnel as it is to set up 6to4.
>

Go to http://tunnelbroker.net/ . I'm willing to bet that it will take a lot
less time than you have spent writing email on this thread. :-)

---

From: Keith Moore <[email-masked]>
Date: Thu, 9 Jun 2011 14:53:19 -0400

On Jun 9, 2011, at 2:45 PM, Lorenzo Colitti wrote:

> On Thu, Jun 9, 2011 at 11:37 AM, Keith Moore <[email-masked]> wrote:
> Actually, this mostly happens in enterprise networks and universities. I don't see why they would want to change this compared to, say, actually deploying native IPv6.

Well if an enterprise network wants to firewall certain kinds of traffic, that's its own business.  The fact that some enterprises firewall ip-over-ip tunnels is not a justification for IETF trashing one particular kind of ip tunnel.

> From the same place that he ran the 6to4 measurements from?

See above.  It's not a valid measurement.   Or the measurement is fine, but comparisons between configured tunnels and 6to4 on the basis of such measurements are not valid.
 
> Go to http://tunnelbroker.net/ . I'm willing to bet that it will take a lot less time than you have spent writing email on this thread. :-)

That's who I was using before.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Jun 2011 07:01:02 +1200

Hi Lorenzo,

> published 6to4 addresses, those connections would still fail.

To be clear, that statistic applies to clients whose SYN packet reaches
the server, but who never respond to SYN/ACK. It's a presumption that
the problem is Protocol 41 filtering - probably correct, but there are
other possible causes.

Also, we have no possible way of knowing how many clients send SYN packets
towards a 6to4 anycast relay, but those packets are blackholed and never
reach the intended server. From the client's viewpoint, this also looks
like a missing SYN/ACK, leading to retries and eventual fallback to IPv4.

In other words, the real failure rate may be much worse than Geoff reports,
but we have no way of measuring it.
> and that the failure rate is much lower.

Er, I'm currently on 2001:388:f000::xxxx
Do you have an algorithm that will tell you whether that is native
or a configured tunnel?

    Brian
> ------------------------------------------------------------------------
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Jun 2011 12:03:55 -0700

> Do you have an algorithm that will tell you whether that is native

Not perfectly. But you can look at things like MSS and MTU.

---

From: Tim Chown <[email-masked]>
Date: Thu, 9 Jun 2011 20:34:56 +0100

I agree the draft should be progressed, so add another +1 to the 'just ship it' people.

On 9 Jun 2011, at 18:39, Keith Moore wrote:
>  If pain associated with 6to4 provides an additional incentive for ISPs to deploy native v6, and for users to use native v6 when it becomes available, that's a Good Thing. 

The pain though is felt by the content providers, who still see too much brokenness.  

> I confidently predict the reclassification to Historic will be roundly ignored not just by Apple product engineering but by the entire industry.  We're smart enough to recognize that we're not the…

Well, the most important point in this is that 6to4 is disabled by default in every device.  Apple did that already, which is good. What is unclear to me though is whether deprecating 2002::/16 means that prefix would no longer be routed, as per 3ffe::/16, or just 'reserved' so it's not reallocated later.

> That's who I was using before.

Our staff and students find the HE broker easy to use, though I believe some also use other brokers.  One student did a final year project this year developing a Linux home router which included HE broker support.  It was simple to use/integrate.

On 9 Jun 2011, at 19:56, james woodyatt wrote:
> I need *native* IPv6 into my home in San Francisco for my day job

Have you considered deploying/adding IPv6 VPN support at your day job?  So your VPN from home to work gives you IPv4 and IPv6?  This is quite a nice model, and is starting to appear in UK universities, and I use it myself for IPv6 training. At least one big vendor offers this today. Users are familiar with VPN use, so adding IPv6 with that comes naturally, and $dayjob provides the support, so you're in control.

> Meanwhile, 6to4 works fine on their network so long as remote IPv6 destinations have a working return path route to 2002::/16, i.e. they are complying with I-D.ietf-v6ops-6to4-advisory now.

That 'so long as' is the crux though.

Tim

---

From: Martin Rex <[email-masked]>
Date: Thu, 9 Jun 2011 23:31:05 +0200 (MEST)

> One voice doesn't make it "consensus to drop".

In the IETF, that is supposed to be possible.

A single technical or procedural issue that is raised before or
during Last Call and not resolved precludes  IETF rough consensus.

intention behind this include (using words from rfc2418):
   good working group consensus about a bad design.

While the Tao (rfc-4677) is only informational, it seems to capture
the IETF spirit quite good:

   "We reject kings, presidents and voting.
   We believe in rough consensus and running code".

   The lack of formal voting has caused some very long delays for some
   proposals, but most IETF participants who have witnessed rough
   consensus after acrimonious debates feel that the delays often result
   in better protocols.  (And, if you think about it, how could you have
   "voting" in a group that anyone can join, and when it's impossible to
   count the participants?)  Rough consensus has been defined in many
   ways; a simple version is that it means that strongly held objections
   must be debated until most people are satisfied that these objections
   are wrong.

or look at rfc-4858, later parts of section 3.2, another Informational
but valuable document.

e.g. if an implementor raises an issue, one should carefully listen
and talk about it, even if it is just one single implementor.
The opposite, an implementor that does not see a problem is not
proof of anything (as we can see from regular interop problems
showing up only during interop tests).  Reading specs correctly
(and carefully) seems to be less common than is desirable.

The purpose of the discussion is to seperate issues of taste (where
significant majority decisions are OK) from technical&procedural
issues and resolving all of the latter categorie(s) or determining
technical issues to be out-of-scope.

WG chairs and ADs have a significant discretion, and I've seen it
happening that they got too personally involved, inducing a non-marginal
bias on the issue resolution process in situations where this was
unnecessary and not appropriate.  That may or may not result in
worse decision.  But it is conceived as unfair by those holding
the objections and a problem by itself because it regularly
taints other discussions on other work items.

-Martin

---

From: Michael Newbery <[email-masked]>
Date: Fri, 10 Jun 2011 14:01:28 +1200

> I confidently predict the reclassification to Historic will be roundly ignored not just by Apple product engineering but by the entire industry.  We're smart enough to recognize that we're not the…

I agree with James on this.
6to4 is better than nothing. This RFC won't make existing 6to4 go away. Those of us who want to support our users may continue to support 6to4 relays until we can get native v6 working---at which point said relays can die as far as I'm concerned.

There is little point in making a better 6to4 protocol. Better to put that effort into deploying native v6. (There _is_ some point in stopping protocol 41 brokenness, which helps 6to4---but also helps other things too.)

If we want to identify a great evil whose time is passed and which should die, die, die! then I quixotically suggest LSN. But again, rather than waste time on that, can't we just move on and invest in native IPv6?

+1 to the draft

---

From: james woodyatt <[email-masked]>
Date: Fri, 10 Jun 2011 10:15:19 -0700

On Jun 9, 2011, at 10:42 AM, Lorenzo Colitti wrote:
> 
>  We have data that clearly shows that Mac OS 10.6.4, which uses 6to4 by default...

I don't want anybody to be misled by this statement.  I think what Lorenzo meant to say is that Mac OS X 10.6.4 and earlier doesn't implement the policy table in I-D.ietf-6man-rfc3484-revise, which prefers IPv4 source addresses over 2002::/16 IPv6 source addresses.

Mac OS X has *never* used 6to4 by default.  The scenario Lorenzo is talking about is where a router is advertising a 6to4 prefix onto a native IPv6 link.  On those links, Mac OS X 10.6.4 and earlier will treat 6to4 prefixes equivalently to any other IPv6 prefix when making address selection decisions.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 10 Jun 2011 10:22:39 -0700

On Fri, Jun 10, 2011 at 10:15 AM, james woodyatt <[email-masked]> wrote:

> I don't want anybody to be misled by this statement.  I think what Lorenzo
> meant to say is that Mac OS X 10.6.4 and earlier doesn't implement the
> policy table in I-D.ietf-6man-rfc3484-revise, which prefers IPv4 source
> addresses over 2002::/16 IPv6 source addresses.
>

Yes, of course. I was trying to keep it short.

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 10 Jun 2011 10:56:50 -0700

On Jun 10, 2011, at 10:43 AM, Michael Richardson wrote:
> 
> This all reminds of how killing the mbone killed multicast.

Getting grumpy email from van because I sourced more than 128Kb/s killed the mbone, it was a toy. 

joel

---

From: Keith Moore <[email-masked]>
Date: Fri, 10 Jun 2011 14:28:58 -0400

> Mac OS X has *never* used 6to4 by default.  The scenario Lorenzo is talking about is where a router is advertising a 6to4 prefix onto a native IPv6 link.  On those links, Mac OS X 10.6.4 and earlie…

thanks for clearing that up.  I was pretty sure it wasn't true, but you saved me the trouble of reinstalling 10.6.4 to prove it.

Keith

---

From: Michael Richardson <[email-masked]>
Date: Fri, 10 Jun 2011 13:43:57 -0400

>>>>> "Lorenzo" == Lorenzo Colitti <[email-masked]> writes:
    >> Why are you trying to make life harder for developers of IPv6
    >> applications?  There's no reason at all that an application
    >> developer should have to set up a special-purpose network just to
    >> test an IPv6 application.
    >> 

    Lorenzo> No, we're trying to make their lives easier, by suggesting
    Lorenzo> they use something that actually *works*.

    >> Realistic testing of applications needs to be done on real
    >> networks, or a least an approximation to real networks.  Testing
    >> IPv6 using 6to4 over public IPv4 obviously isn't perfect, but
    >> it's a hell of a lot more realistic than setting up a lab network
    >> and confining one's testing to that.

    Lorenzo> So use a tunnel broker.

My tunnel broker has a machine with broken IPv4 routing, which they
can't fix.   It's been down for a week+ now.   We had to renumber that
location in time for World IPv6 day.  We only had 6 machines that were
using their non-autoconfigured addresses, so the rest was just a s///g
in the DNS zone file.

6to4 would have turned this into my problem (which I could have fixed),
but since some places like google refuse to run their own 6to4 relay, I
can't really use 6to4 to talk to.  Thanks.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.